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