rubyonrails and cgikit comparison

[Lennon Day-Reynolds]

I've been working on some DHTML-based application prototypes recently,
and have thought about exactly these issues, as someone else (read: a
non-programmer) will likely be responsible for some layout and
content-editing work.

In effect, the big question is how many domain-specific languages you
need for web application development, and who should be responsible
for learning and using each of them. In most any modern project,
you're going to have at least three in the web tier alone: HTML,
JavaScript, and CSS. Your backend will then included some core
implementation language, (preferably Ruby, of course) and usually SQL.

If you're using a templating language as well, (as opposed to the
ASP/JSP/PHP style) that brings the language count up to six. Even if
your designers can handle the four front-end languages, you're going
to need programmers who handle the context switches between all six
without too much difficulty, as even minor bugs may result from issues
that cross boundaries between many different tiers: i.e., a
badly-formatted string in a SQL field gets mangled somehow in the
backend, after which the template dumps bad HTML that your CSS and
Javascript can't format or control properly.

(Those frameworks that try to use XML for everything don't really help
much, either: they just tend to end up with another three or four XML
grammars to work with, and often throw some embedded DSL in for things
like conditional expressions in attributes.)

Anything you can do to reduce this language count is worthwhile, IMHO.
That's why I prefer the "server pages" model (which Rails basically
uses) to specialized template langauges -- your designers may not be
able to do more than the most basic, idiomatic work with the
templates, but at least your programmers won't have to page out one
language for another just to check a change in the display logic. With
a framework life Active Record, you can also mostly eliminate SQL from
your backend programming, which further reduces the DSL count, for
common tasks at least.

The other option which seems to work well is using Javascript as a
display logic language. It would be interesting to see more
Javascript libraries designed for use by designers that either
"compiled" into some sort of backend code, or masked RPC-based calls
to your app server, so that the calls could even be intermixed with
client-side DOM processing.

My slightly-more-than-$0.02,

Lennon

 

[Martin DeMello]

To introduce a further heresy: why restrict the use of the real
programming language to logic (conditions, loops, etc)? Wouldn't it
be nice to use a real programming language, with real abstraction, for
the rest of the template too, instead of a just markup language? A
lot of problems simply go away if you use Ruby to generate the HTML
directly rather than messing around with templates, bindings, and
embedded code.

This is something I've been wanting for a long time, but I've never seen
a good implementation of it. What I want is both a powerful programming
language, and a reasonably declarative way of specifying the layout
(including things like significant whitespace - this is IMO somewhere
where it makes sense).

martin

 

[Nicholas Van Weerdenburg]

In my mind, indirection = encapsulation in this case, with a complexity
vs. flexibility tradeoff. That can be beneficial to even a simple
programmer doing both jobs (programmer, HTML designer). Indirection is a
basic form of interface helping drive low coupling and high cohesion (or
it's over-designed OO making the code extendable and maintainable if you
ever manage to figure it out )

For instance (please excuse the trivial example), if using a library
that provides addresses, and you have

@invoice.date

and you now want European date formating. In a large date driven
application, you would may have 30 @invoice.date's. With a binding
between presentation and application logic, you only have 1.

Considering how much handler code must be written for a given page
anyhow, it doesn't seem too awkward to me to have all insertions via
indirect bindings. I suppose on the other hand, you may have designed a
very good library/application with other "cut points" a layer up, making
this very redundant, and thus needless indirection. Or, the programmer
is a good instinctive programmer and naturally refactor volatile logic
into appropriate helpers.

Now that I've said, it occurs to me that my thinking may be too
interface-centric from my C++ and Java experience, and Ruby's duck
typing more naturally allows for other "cut points" by virtue of easy
creation of proxy objects in other parts of the UI (actually, thinking
about this now, this does seem very likely). So, maybe some of the
"traditional" thinking about web frameworks maybe goes out the window.

I do like the idea of the template language being ruby. It would be
interesting if a setting could force template code to be a specific
subset of ruby- e.g. more forcably conditional and application logic out
of the html. A recent ruby-talk post referenced a Paul Grahm Lisp
article where he hypothesized about the possibility of Lisp being good
for solitary hackers, and Java for "pack" programming -aka larger teams,
where cumbersome explicit types and interfaces are necessary for the
team to maintain the "theory" of how the app should be structured,
extended and integrated. This concept would weight heavily on templating
approaches, I think. Maybe an arbitrary templating language that is
seperate from the application logic language is an essential feature of
web app platforms in the context of "pack" dynamics?

Regards,
Nick

Florian Weber wrote:
....

 

[Kirk Haines]

On Tue, 27 Jul 2004 20:00:38 +0900, Martin DeMello wrote

This is something I've been wanting for a long time, but I've never seen
a good implementation of it. What I want is both a powerful programming
language, and a reasonably declarative way of specifying the layout
(including things like significant whitespace - this is IMO somewhere
where it makes sense).

Martin, take a look at Borges.

http://borges.rubyforge.org


Kirk Haines

 

[Martin DeMello]

Martin, take a look at Borges.

http://borges.rubyforge.org

Thanks, I'll take a look. I'm more interested in static page generation
than in webapps per se, so I'd thought it'd be overkill for my purposes.

martin

 

[Kirk Haines]

On Wed, 28 Jul 2004 02:47:13 +0900, Martin DeMello wrote

Thanks, I'll take a look. I'm more interested in static page generation
than in webapps per se, so I'd thought it'd be overkill for my purposes.

Maybe I'm misunderstanding what you are looking for, to. Can you explain a
little more what you are looking for? Are you talking about pages with 90%
static content and a little dynamic stuff here or there? The stuff that is
not completely static but falls well short of a full fledged web application?


Kirk Haines

 

[Martin DeMello]

On Wed, 28 Jul 2004 02:47:13 +0900, Martin DeMello wrote


Maybe I'm misunderstanding what you are looking for, to. Can you explain a
little more what you are looking for? Are you talking about pages with 90%
static content and a little dynamic stuff here or there? The stuff that is
not completely static but falls well short of a full fledged web application?

That too, but mostly static sites generated from dynamic content (i.e.
if the content changes, the relevant pages are simply regenerated, but
from a websurfer's point of view it's static). I keep thinking that
there has to be something better than HTML/CSS to write the view in,
even if I can't come up with it myself. So far I've looked at
ClearSilver and Amrita, which didn't quite have the 'high level' feel I
was looking for, Velocity, which came close but I'd prefer something
that operated better with Ruby, and CGI.rb which got ugly very fast for
complex pages (maybe I was doing it wrong, though).

martin

 

[Kirk Haines]

On Wed, 28 Jul 2004 20:36:47 +0900, Martin DeMello wrote

That too, but mostly static sites generated from dynamic content
(i.e. if the content changes, the relevant pages are simply
regenerated, but from a websurfer's point of view it's static). I
keep thinking that there has to be something better than HTML/CSS to
write the view in, even if I can't come up with it myself. So far

Hmmm. This may be no help to you at all, but I am doing something like that
with Iowa. Let me explain what I am doing and if it sounds at all
applicable, I can help you try it out.

Some of my clients have access to a content management system with which
they can control content on their pages. This system was originally written
in uninspired Perl. I have been slowly converting pieces of it to Ruby and
improving its capabilities at the same time.

In the past the content was stored in a database, and for every page hit a
db query took place to get the content. I recently switched the system to
use Iowa instead of Perl CGIs for generating the pages, and then I took it
one step farther.

The CMS system now saves the content in the database only for use by the CMS
system. The actual pages are generated as Iowa components by the CMS system.

Every time page content changes, the CMS system will regenerate the
component into a static file. I actually did this because it now lets me
provide dynamic capabilities to clients in the form of Iowa components that
they can just include into their web pages via the CMS system. So, one
company might have access to a set of components that allows data entry and
report generation, and they can control where and how those capabilities are
reached simply by embedding something like:

<IssueView idx="7"/>

into the CMS system. It all gets rolled into a component for that page and
looks static, even though it's really not.

Now for the part that may make this of no use to you. There's no real
magic here. Iowa has a seperation of code from HTML. It solves a lot of
the same problems that Rails does, but in a very different way. So, you
write your static HTML in one file. You can include results of executing
Ruby methods in your HTML, and there are a few really simple markup tags for
handling conditions and loops.

<p>The current time is: @current_time</p>
<repeat oid="number_list">
@number <if oid="is_winner?"><b>This one is a winner!</b></if>
</repeat>

Soooo....you'd still be creating your static content in HTML/CSS, and just
using Ruby to create whatever dynamic portions are in it, but the Ruby code
is all segregated into a seperate file.

If this sounds like it might be helpful to you, give me a shout and I'll
help you get going.


Kirk Haines

 

[Martin DeMello]

Every time page content changes, the CMS system will regenerate the
component into a static file. I actually did this because it now lets me
provide dynamic capabilities to clients in the form of Iowa components that
they can just include into their web pages via the CMS system. So, one
company might have access to a set of components that allows data entry and
report generation, and they can control where and how those capabilities are
reached simply by embedding something like:

<IssueView idx="7"/>

This bit sounds interesting - I've mentally bookmarked it for if I ever
do something on that scale. I'm afraid that for small scale work all I'd
really be using it for is Yet Another Template System.

For a concrete example of the type of thing I'm talking about, the first
time around I did http://zem.novylen.net/filk/filkindex.html using a
handrolled template, manually running a ruby script to generate the HTML
files from some minimally marked-up text and scping them over to my
public_html directory. I've been meaning to rewrite that using a cron
job that scans a 'source' directory for incoming files and generates the
html pages itself. I was going to do it using a template as usual, but
the post that kicked off this subhread reminded me of my abortive
efforts to do it all with CGI.rb's html generation made me wonder if
someone had come up with a better way.

martin

 

[Thomas Leitner]

| Thanks, I'll take a look. I'm more interested in static page
| generation than in webapps per se, so I'd thought it'd be overkill for
| my purposes.

Maybe webgen is what you want, it is a "template based web page
generator".

webgen.rubyforge.org.


Thomas Leitner