Rapid Application Development Frameworks like Rails, Django and Python provide a flexible alternative to commercial content management systems. Instead of trying to shoehorn a website into a rigid format of pages and blog posts, RAD frameworks allow you to build custom Content Management solutions using your own language.
In this post, I will show how the Grails Application Framework, which is built on top of java technologies like Spring, Hibernate, Jetty and the Groovy dynamic language, can be used to quickly convert an existing static site into one that can be managed by someone who is non-technical.
This series has 2 parts, in the first, I will talk about setting up a domain model for your CMS. In the second, I’ll talk about what is needed to distill all the content that live inside static web pages into small, mean gsp pages.
To CMS or not to CMS, that is the question
To me, there are many advantages that come from using a rapid application development framework like Grails instead of ‘the old fashion manual way’. My top pros are:
- Anyone can update the content: after the CMS process, the content in these pages becomes as easily editable as a blog post. This means that less technical help is needed to update the content.
- Easier to extend: tools like Grails have an extensive collection of plugins and enhancements that take away a lot of complexity in adding functionality. Search, comments, star ratings, security, Flex integration, sending email and twitter/facebook integration all come pretty much free and easy to do.
- Simpler layouts: static pages suffer that you have to copy and paste a lot of the same content across different pages. Grails has a very rich page template engine with a PHP-like ability to control execution that makes writing layouts much less repetitive and easier to make site-wide changes.
However, there are also a few cons to the starting to use tools like Grails:
- More technical expertise needed: now you need a more dedicated person that not only knows about creating HTML and graphics, but also has the programming knowhow to update and add features to the site. The skillset is definitively different, and surely more expensive.
- Hosting and Deployment becomes more complicated: not all these features are available for free. And the hosting of the site definitively would require a more powerful server and even setting up a database for these purposes. This can become daunting and not cost effective for some. But services like mor.ph and eapps are popping up to make affordable Grails hosting more easily accessible.
- Messier Navigation: With static pages, you don’t worry about which data gets included in which page. With grails, you need to spend more time managing the data that goes into your screens.
Getting Set Up
Step 1. Get Grails
If you haven’t already, download and install the latest version of Grails. You can download the latest version from the Grails website and follow the installation instructions. Don’t worry, I’ll wait. You will notice that unlike the Django or Rails installations, you don’t need to install a database or a web server. This is because Grails already comes with an embedded Jetty web server and HSQL database.
Step 2. Create your application
Open up a console window and type:
If everything has installed correctly, you should see a message that says something along the lines of Created Grails Application at /Users/tomaslin/cmsdemo. If you run into any major installation issues, the Grails mailing list is filled with extremely helpful folks that can help you out.
Great, let’s get to the interesting part.
Plan Your Project
For this post, I will revisit a site I built about 2 years ago for my supervisor, you can see it at http://www.educ.ubc.ca/faculty/shapka. The site is a very simple site that showcases the research projects, courses, publications and lab members for a professor. Although I did the original design, the site has been re-skinned and updated. But the structure of the data remains the same.
Unlike the traditional CMS approach of sites like Joomla, Drupal or WordPress, we start building the site from the bottom up. This means that instead of thinking of your site as rigid pages and sections that go together, like IKEA furniture, you get to think of the site you are building as individual lego pieces that get assembled however you want.
Think Pieces, Not Pages
When planning your project, throw away the idea of a page, and think of common components that make up your site. If you have ever used Java Beans or Flex Components, it’s exactly the same idea – a very specific piece of data backed up by a piece of graphical user interface. These pieces are then assembled together using Grails.
How do you come up with a good domain model? Think of building blocks. You have your 2 dot minipieces, long rectangle pieces and Darth Vader minifigs. In the same way, you should think of the different objects that your site is trying to present. Is there a specific page for that kind of content? Then it should probably have it’s own separate piece. Is this kind of content used more than once on a given page but with different content? Then it should probably have it’s own piece.
Structurally, you are looking for things that live inside tables and unordered lists that are NOT navigation elements.
Going over the site, I came up with the following pieces:
- Section – a general piece of information that has a title and a description. This is my rectangular gray Lego piece where I will put all the bits of content that I can’t fit with another more specific piece of content.
- Projects ( http://educ.ubc.ca/faculty/shapka/research.html )
- Courses ( http://educ.ubc.ca/faculty/shapka/shapka.html#teaching )
- Members ( http://educ.ubc.ca/faculty/shapka/members.html )
- Alumni – lab members who have graduated.
- Publications (http://educ.ubc.ca/faculty/shapka/shapka.html#publications )
- Quick Links – links on the front page
Notice how this structure is specific to the site itself, and would probably have been difficult to configure with a structured CMS. A similar data model for a corporate website might be: Section, Products, News, Press Releases.
Build Your Domain Objects
A Grails Domain Object is a Groovy class that describes the Lego pieces in your system. I will build the section and Member Domain objects here as an example, but you would have to do this for all the pieces that you come up with.
In my console, I go into my cmsdemo directory and call the generate function:
If I go into my cmsdemo/grails-app/domain directory, I should see a new file called Member.groovy, here is where I will tell Grails about this lego block. For every attribute that I want to keep in my content management system, I create a new property in the Member.groovy file.
Each piece of the content I have identified would go into its own domain object. You can also set relationships between them, but I won’t cover that here. ( but I’ll give you a link )
CRUD stands for Create, Read, Update and Delete. And Grails has automatic facilities for generating these based on the domain model. Now that I have defined all my lego bricks, I can tell Grails to automatically generate the screens to help me edit them. I call the following command
This tells Grails to build all the screens ( views ) and logic ( controller ) needed to support this domain class. Run you application by calling
And navigate to http://localhost:8080/cmsdemo/ in your browser.
Click on the MemberController link. You should see this:
That’s not very intuitive, isn’t it. All the fields are in alphabetical order, and there is no error checking. And wouldn’t it be nice to be able to enter more than one line in fields like Research Interest?
Fortunately, this is easily done via the the constraints ( currently empty ) inside the Member.groovy file. Ope it again and add some constraints, which gives you error checking and controls the look of widget. By adding the text in Yellow, I can dictate the widgets and get automatic email validation in Grails, and a dropdown for the different type of students that go there.
Note: after you have changed the constraints, invoke
to see your changes. With these screens in place, we can now add new members easily. Repeat for all the objects we have identified and we have a very simple way of updating all the content of our existing website.
In the time that it would have taken me to read the Joomla manual to figure out where custom properties go, I have been able to create all the model and edit screens for my existing website. We’re almost there.
That concludes everything you need to set up your domain model and screens to edit your data. In the second part, I will talk about how to hook up this data for lean, mean gsps.