Ruby tools for managing static websites?

Are there Ruby tools to help webmasters manage static websites?

I’m talking about regenerating an entire static website - all the HTML
files in their appropriate directories and sub-directories. Each page
has some fixed parts (navigation menu, header, footer) and some
changing parts (body content, though in specific cases the normally
fixed parts might change as well). The tool should help to keep site
editing DRY every piece of data, including the recurring parts, should
exist only once.

The above should be doable with any decent templating tool, such as
those forming part of most CMSes and full-stack web-frameworks.
Normally I might have just resorted to a CMS/web-framework, running
locally on the webmaster’s station, with the only addition being a
mechanism for generating all pages composing the site and saving them
as files.

But such a solution might not be enough, as the system I’m looking for
must be able to control the physical traits of the website as a
collection of files - e.g., creation and distribution of files among
several physical directories and subdirectories.

Any advice would be appreciated,
-Chris

Chris P. wrote:

Are there Ruby tools to help webmasters manage static websites?

webgen.rubyforge.org.

I personally find it great and easy to use. See their web page there,
and try a look at mine ;-)…

Vince

On Tue, 31 Oct 2006 12:08:24 -0000, Chris P. [email protected]
wrote:

Are there Ruby tools to help webmasters manage static websites?

Check out Rote - sounds like it’s custom-designed for your needs :slight_smile:

http://rote.rubyforge.org/

On Tue, 31 Oct 2006, Chris P. wrote:

The above should be doable with any decent templating tool, such as

Any advice would be appreciated,

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.

cheers.

-a

On 31/10/06, Chris P. [email protected] wrote:

The above should be doable with any decent templating tool, such as

Any advice would be appreciated,
-Chris

There’s also Hobix (http:.//www.hobix.com) although it doesn’t look
like there have been any updates there for a while.

Farrel

On Wed, 1 Nov 2006 [email protected] 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.

You can do that with a relatively new IOWA feature, too (introduced in
this 0.99.2.x development chain).

Set docroot_caching=true in the config and IOWA will write the generated
content into the docroot. Depending on your webserver config, that file
will, on subsequent requests, either be served as a static file by the
webserver, or the IOWA handler will serve it statically itself. If you
need to regenerate the static files, just delete them, and the next
request for them will be processed dynamically and saved.

Right now this is an all or nothing feature, but I have plans to enable
one to specify that only certain urls or regions of a site be
dynamically
cached in this way.

Kirk H.

On 10/31/06, [email protected] [email protected] 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 :slight_smile:

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

On Wed, 1 Nov 2006, Chris P. wrote:

files and directories. You could conceivably map directories to
certain internal links etc.)
besides the crawler/saver script, which I’m not sure is completely trivial:
than ERB.
can’t you elaborate a bit? :wink:

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

<…>

Static websites don’t require an ORM, and don’t use business objects.
So ActiveRecord would be pretty much useless.

Some static sites are dynamic but with slow dinamics :). For these it is
very
convenient to have content in DB and have administration interface
written in Rails.
Because content doesn’t change so often (or for security reasons) such
site then can
be crawled to static pages which are put on public web server.

When the need for really dynamic site will come this way will make
transition very easy.

<…>

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

This is not true. Not everything in the routes must be a controller.

One could easily imagine a
static-website management tool integrating a much better - or at least
more suitable - templating solution than ERB.

I guess I either have a problem with my imagination or my needs
are so simple that ERB and some helpers suit them very well…

Regards,
Rimantas

On Wed, 01 Nov 2006 06:08:06 -0000, Chris P. [email protected]
wrote:

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 :slight_smile:

Actually, Rote allows you to mix in ActionView helpers to your pages -
we’ve already made a start on making the Page API compatible for that.
Obviously not everything makes sense in a static site, but the tag
helpers, form helpers, etc. can be pretty useful. All it takes is:

require 'active_support'
require 'action_view'

class Rote::Page
  include ActionView::Helpers::FormHelper
end

dropped in the Rakefile rote gives you. We’re also looking at getting
partials working properly, too.

</hard-sell :slight_smile: >

On 11/1/06, Ross B. [email protected] wrote:

Thanks a lot for the information. Rote is among the handful of tools I
intend to seriously check out now. There is going to be a contest, and
though I prefer Ruby as a languae, Python sent several worthy
contestants which can’t be ignored.

I’ll publish results here, probably next week.

-Chris

On Oct 31, 2006, at 4:08 AM, Chris P. wrote:

Are there Ruby tools to help webmasters manage static websites?

ZenWeb http://rubyforge.org/projects/zenweb

clean, simple, powerful.

Supports all of the requirements you listed (nav, header, footer) via
a simple pipelined renderer mechanism. I use it for my 259 page
static website. I mainly like it because it allows me to focus on
content and let it deal with the rest. I just write in plain text for
95% of the site and it just works.

Chris P. wrote:

The above should be doable with any decent templating tool, such as

Any advice would be appreciated,
-Chris

Article from Martin F. about using rake (ruby’s version of
make/ant/etc) to generate his static website

http://www.martinfowler.com/articles/rake.html

On 10/31/06, Vincent F. [email protected] wrote:

Chris P. wrote:

Are there Ruby tools to help webmasters manage static websites?

webgen.rubyforge.org.

I personally find it great and easy to use. See their web page there,
and try a look at mine ;-)…

I have one fairly serious problem with webgen - there’s no way to just
regenerate a single page. Very annoying during development. Other
than that, it’s been a great tool.

martin

On Nov 2, 2006, at 5:39 AM, Martin DeMello wrote:

I have one fairly serious problem with webgen - there’s no way to just
regenerate a single page. Very annoying during development. Other
than that, it’s been a great tool.

Does it do the whole site? ZenTest does incremental builds as
necessary. That was requirement #2 and couldn’t imagine doing full
builds every damn time (for one, google likes to know what actually
updated).

On Thu, 2006-11-02 at 22:39 +0900, Martin DeMello wrote:

I have one fairly serious problem with webgen - there’s no way to just
regenerate a single page. Very annoying during development. Other
than that, it’s been a great tool.

Rote takes care of that thanks to Rake, with your pages as file tasks -
so you can build a page individually and do incremental builds. Another
bonus with that is that all dependencies are registered - if (any of)
the layout(s) or ruby code changes, the page will get regenerated.

On Nov 1, 2006, at 11:22 AM, Alder G. wrote:

On 11/1/06, Ross B. [email protected] wrote:

Thanks a lot for the information. Rote is among the handful of tools I
intend to seriously check out now. There is going to be a contest, and
though I prefer Ruby as a languae, Python sent several worthy
contestants which can’t be ignored.

I’ll publish results here, probably next week.

Okay, I have a similar problem and I’m curious as to the other
options (i.e. the Python suggestions)


Craig B.

AIM: kreiggers

On 11/2/06, Ryan D. [email protected] wrote:

updated).
Yeah :frowning:
http://rubyforge.org/forum/forum.php?thread_id=7986&forum_id=1268

Does zenweb have macro/helper support? I looked briefly at it but it
seemed to be a site management system, with not much help for making
individual page generation easier.

martin

On Nov 3, 2006, at 5:31 AM, Martin DeMello wrote:

Does zenweb have macro/helper support? I looked briefly at it but it
seemed to be a site management system, with not much help for making
individual page generation easier.

While ZenWeb is site-based, it has a ton of functionality at the page-
level. The most powerful of which is probably the metadata system. It
probably fits your notion of “macro/helper”. If it doesn’t, it is
trivial to add new renderers that do.

On 10/31/06, Chris P. [email protected] wrote:

Are there Ruby tools to help webmasters manage static websites?

Have you seen Yurt (http://yurtcms.roberthahn.ca/)? It has a small,
Camping-basd admin front-end. It’s a pretty simple file-based tool for
generating a static website.

  • Dimitri