From: Kirk Haines <khaines@...>
Date: 2004-02-06T02:10:43+09:00
Subject: Re: Ruby Web Application Framework Roundup

On Fri, 6 Feb 2004, paul vudmaska wrote:

> In a simple CMS system i'm creating, i have a ui that
> allows the owner of the site to edit/create (static)
> content on the fly. Then i started thinking that i'd
> like to have some smarts in these files. Instead of
> setting up a harnessing mechanism with Amrita, i added
> a property to the content, executable, and if it is
> on, i complile the text through the eruby compiler and
> eval the code. Dangerous, i know, but it works
> amazingly well so far. Now, I can create content as
> well as logic  on the fly. Right now, within these
> files, the world is my oyster (read destruction zone
> :). 

I used to be a big fan of mixing code right into the HTML, but have, over 
time, developed an aversion to that paradigm.  I don't find that the 
advantages outweigh the disadvantages.

I understand where you are coming from with the approach you have taken.  
I have a static content CMS system that many of my clients use to maintain 
their sites.  I'm reimplementing it in Ruby with better design and a 
better feature set, and one of the things that I wanted to do was to allow 
for the possibility of executable content.

What I have settled on is, basically, a file permissions sort of 
arrangement for the web content.  Each component of content has a 
presentation file, and may have a code file.  Whether a site and a user is 
allowed access to the code files is set by permissions flags.

This lets me setup components that do things like handle the site 
navigation creation and basic page layout, and lets me make them 
uneditable by the client, or lets me make the code portion uneditable, 
whil still, at least potentially, giving the client access to at least 
some of the power of code, if they want/need it themselves, while still 
keeping the code blocks out of the HTML.
 
> This has obvious advantages(and disadvantages), but it
> also has one BIG advantage that is not immidiately
> clear - i can compile the code with eruby and save
> THAT, <b>which is now pure ruby</b>, into a supporting
> table. So it is compiled only ONCE. 

That is nice.  One of the future enhancements for Iowa that I am looking 
at is the ability to save the components after they have been parsed so 
that on startup, they do not necessarily all have to be reparsed.  While 
the system is running, the components only get reparsed if they change, 
but during startup, if there are a lot of components with a lot of HTML in 
them, parsing all of them can take a while.

> The one thing missing from many of these Web
> Application Platforms/Frameworks is the ability to
> simply create websites - with content mgt and a common
> look and feel. I'm not as interested in the webobjects
> or j2ee platform/methodology as i am in creating sites
> that are easy to build and maintain. For me, i guess
> i'm more interested in a Web Site Platform - that i
> can extend as i see fit. The above works pretty good
> for me so far. I'd be interested in any constructive
> crit you may have.

That is more or less where I am headed, as well.  In my case, clients are 
typically businesses that want to be able to manipulate their site content 
at will without having to worry about the tricky bits like overall site 
layout or getting the navigation right.  So I need a system that lets me 
give them an overall structure, provide certain tools or components to 
them for their use, and that gives them control while at the same time 
limiting the damage that they can do if they mess up.  It needs to be easy 
to setup a site in, easy to change look and feel aspects of the overall 
site with, and I want to use Ruby because I just enjoy using it so damn 
much.

Iowa is about perfect for the way that I work, at least as I have adjusted 
it, and I'm hopeful that after I release the current in-progress code 
tree, that a few other people might give it a whirl.


Kirk Haines