I'm a big fan of using the "right tool for the job," so it's with a little reluctance that I confess to my latest technological sin - using Rails to create a largely static "web 1.0" style web site. I know, I'm totally square and not hip at all.
It's a common scenario - you have a few "base" pages that are modified infrequently. Things like "about this site" or "history" or what have you - things that you might manage with a CMS of some sort. The data on these pages needs to be somewhat free-form, since they're all effectively "one offs," but they also need to share the same general page layout, menus, other stylistic elements.
Realistically, server side includes can meet this niche reasonably well. But if and when the content does need to change (or pages need to be removed or added), you're faced with editing flat files on the server which can be cumbersome for minor edits (especially if the system is designed to allow edits from novice users). You also are limited to static html, which is problematic if you want your menus or status text to change based on the state of your application or its content.
Anyway, long story short, I decided that creating a simple Rails resource for this purpose wasn't a bad idea. Even though rails was designed for more complex applications, it's quite capable of doing simple tasks like this, and in some ways I found it faster to work with than flat files. You also gain the ability to use ruby statements within your layouts, and you can use hpricot or another processor to tidy up possibly mis-entered HTML before it hits the browser.
Now, there are some considerations.
Firstly, do you use a real resource, or do you rely on view fallthrough with no actions defined in the controller? You can completely eschew typical MVC methods and just create views that match the names of your pages, with the net result being your content is all stored in flat html.erb view files. This has some advantages - namely, you can use ruby directly within the page content - but I ultimately decided to use a full MVC, RESTful resource instead, with each page being an instance of a "page" model with its content and metadata stored in the database. The primary advantage of this method is that you can edit and create new pages directly from the browser.
Next, I had to decide whether to manually map routes or to rely on map.resources. I struggled a bit with this decision - there are some advantages to manually mapping each page, either at the apache level or with routes.rb. The RESTful URL scheme is not entirely suited for these sorts of pages - you end up with an extra level in the namespace for the controller (foo.com/controller/ID) if you rely on map.resources, whereas you can map pages directly off of the root if you go for manual routes. In the end I stuck with map.resources, but this is a question that demands real consideration.
You also have to decide if you want to use the typical rails convention of "look up by primary key," which I feel is especially poor for this endeavor. I fixed this by modifying "to_param" in my model to refer to a different field (such as "shortname") and modified my controller's find statements to search accordingly. This allows you to set or change the URL when creating or modifying pages, so you have "pretty" URLs like foo.com/pages/home instead of foo.com/pages/2.
In the end, I'm OK with the results. I can see this as being more of a win for a site that's already planning to use RoR for some heavier lifting and wants to unify everything on that platform - I don't think it makes the most sense when (as I've done) creating a rails app specifically for this purpose. It's honestly not bad, even so - the spool up time with rails was not really that much worse than using apache SSI, and the flexibility gained from it is potentially nice.
Comments
liam @ Thu Jan 08 12:40:07 -0500 2009
Well apparently I am square as well. Because I would like to do exactly the same thing - build a "foundation" RoR site that starts out semi-static but has the ability to become more dynamic as I become more dynamic (which really means I learn more about RoR)... would you mind sharing your app - how you did it, etc??? I am a newbie so any help would be appreciated. Thanks.