From: Chris Pearl Date: 2006-11-01T15:08:06+09:00 Subject: Re: Ruby tools for managing static websites? On 10/31/06, ara.t.howard@noaa.gov wrote: > i'm not quite clear why you wouldn't just setup a rails site and crawl it to > generate the static site? since speed wouldn't be an issue on the rails end > you could just use webrick and an sqlite db to keep things simple and > dependancy free. this gives you a huge toolset to work from and a mailing > list to ask questions on - the only custom work you'd need to do is write a > dedicated crawler script, and even that might turn out to be nothing but a > single wget command if you planned your site carefully. For the needs I described, Rails integrates a lot of features that aren't needed, quite a bit that would have to be awkwardly worked around, and afaik only a little which would actually help. Static websites don't require an ORM, and don't use business objects. So ActiveRecord would be pretty much useless. As for routing, ActionController's abstractions work well for dynamic, RESTful, CRUDy web applications, but very poorly for run-of-the-mill static websites. ActionController is oriented towards objects and namespaces, not files and directories. You could conceivably map directories to controller-namespaces, and files to Controller methods. At best, it would be awkward: adding a directory 5 level deep, which is quite common for a static website, would entail creating a 5 level controller namespace - awkward and rarely done in Rails. I suspect there would be more serious problems the more you stretch the analogy between the not-so-similar metaphors. Off the top of my head, a common directory rename would appear to be a serious pain (you'd have to rename the containing module for all controllers contained within that directory). I.e. Rails would make that operation harder than it would normally be, while a dedicated static-website management tool should make it easier (e.g. by automatically updating certain internal links etc.) The only part that would appear to be helpful is ActionView, and maybe some helpers (most helpers are oriented to dynamic web-application needs: dynamic forms, AJAX etc.) I'm not sure the above overhead is worth it just to get a templating system, that's - let's face it - an integrated ERB :) As for missing stuff, Rails works well for CRUDing business objects, but the simpler metaphor - your old bunch of pages with some common and some unique elements - isn't supported out of the box. I'd basically have to write a simple CMS to organize the content (unique) parts of each page. That's besides the crawler/saver script, which I'm not sure is completely trivial: for example, the way Rails handles embedded files - stylesheets, javascripts and images - is incompatible with the way they are treated in a normal static website. All in all, a file-and-directory based management tool with a decent templating system would seem a much better fit. Especially given that Rails invests mainly in features that aren't required in this case - ActiveRecord, AJAX - and comparatively little in the few features that we do need: the templating system. One could easily imagine a static-website management tool integrating a much better - or at least more suitable - templating solution than ERB. > cheers. > > -a > -- > my religion is very simple. my religion is kindness. -- the dalai lama > > Thanks, -Chris