Chris Pearl
11/1/2006 6:08:00 AM
On 10/31/06, ara.t.howard@noaa.gov <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