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, which is now pure ruby, 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
···
On Fri, 6 Feb 2004, paul vudmaska wrote:
