We had a great time at RailsConf this year. Ben's presentation went well and got a great response from the crowd that attended. I had a chance to chat with some people (both from our local group and elsewhere) about the content of the presentation, and the responses were pretty consistent. For the developers who had faced the same issue of building a dynamic site with a large amount of static content, the solution met their needs. I ran into a lot of people who had just been creating a single controller (e.g. GeneralController) to handle all the static content for their sites. This approach works for a while, but as the static content grows – which was the case when we built the ACVA site – things quickly become cumbersome. I also talked with others who were misled by the title and wondered "why would you use Rails to build a static site?" The answer to that is... "you don't." If you're building a truly static site, Apache, Lighttpd, or Tux are your friends and will serve up static files faster than Rails can. In fact, Ben's solution relies on a front-end web server to serve up the cached pages generated from the static site framework. So for those that missed out, here's what the framework allows you to do (implemented as a plugin-app):

• Upload or create content files – In typical CMS CRUD fashion you can add content directly to the 'pages' table through a web front-end either using a textarea or a standard file upload control. From there, the content is then immediately available in your application.
• Generate site maps – Because the page content is stored in the database and the Page model uses acts_as_tree, we're able to traverse from the root and generate a site map for display. This design decision, along with providing modification timestamps, also helps when you need to generate the XML for use with Google Webmaster Tools and other search engines that use this site map standard.
• Provide customized page-specific variables – Again, because of acts_as_tree in the Page model, we can provide a hierarchical inheritance model for page-specific variables. Setting a variable at the parent level makes it available to all the children with the ability for each child to override the parent's default setting.
• Search for terms in your "static" content – The framework plays well with your current search solution. If you're using Ferret, Solr, or Hyper Estraier you can search both your existing CRUDified content and your new static content.

If you want to test it out, you can download the plugin and view the slides from the Viget site. In the near future, we'll be pulling the code into a public SVN repository – stay tuned.