From: ara.t.howard@...
Date: 2006-11-01T16:24:22+09:00
Subject: Re: Ruby tools for managing static websites?

On Wed, 1 Nov 2006, Chris Pearl wrote:

> 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.

can't you elaborate a bit?  ;-)

well, those a good reasons.  i was interested to hear them because i'm facing
a similar issue.  i'm still convinced that a backend rails app would work:
some of the issues like directory nesting could be handled with something like

   curl http://localhost/sitegen/make_page?directory=foo/bar&param=42

if you take my meaning...  basically the rails app needn't mirror the
filesystem, but might merely be used to to mix data and html in a dry and
high-level way.

that said, i'm also considering using yaml + amrita to generate my site.
basically

   directory/index.html
   directory/template.html
   directory/data.yml

template and data obviously being hidden via .htaccess or some such.  the
script to crawl something like that is nearly a one liner, but it reeks of
data and html duplication...

in any case, i'm still on the fence - let us know what you decide.

cheers.

-a
-- 
my religion is very simple.  my religion is kindness. -- the dalai lama