Rubyonrails and cgikit comparison

ruby-talk
41

The designer is there for that I guess.
I tell him, "hey, the structure of the address has changed. Replace the cgikit
address by 2 tags address1 and address2. Those are just strings". And he know he just has to add <cgikit name="address1"/> and <cgikit name="address1"/> where he sees fit.
Again, he doesn't care of the name of my variable eg.

same thing in rails. you just tell her/him to use @person.address1 and @
person.adress2 =)

but like i said, what do you gain by the indirection if the ruby and the
html programmer are the same person?

I guess it's a question of preference, I find it a bit cleaner.
But do you mean you expect every ruby coder to master HTML like a web designer?

Let me return the question: don't you think there a gain if the ruby and html coders are different persons? (One gain being that none can break the

i guess it really depends. most of the projects i've worked on in the last months
didnt had a special html-guy/designer.. so for me the abstraction of a binding
or anything a like doesnt bring me any advantage and just costs time. but like i said,
thats just me..

for sure you can say that a html-guy would have to learn a bit of ruby to
do more complex templates with rails. but if the project would be using cgikit,
he/she would have to learn cgikit also..

42

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 <khaines@enigo.com> wrote:

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?

43

David Heinemeier Hansson wrote:

Let me return the question: don't you think there a gain if the ruby and html coders are different persons? (One gain being that none can break the
other part's work, like mentioned in my previous mail)

I think I have some perspective on this considering that Basecamp was built using Rails with a separate HTML/design guy and separate programmer. The way that we worked, the HTML-guy prepare a template with just HTML.

I usually work the other way around: I make a first draft template, and the designer
enhance it. Maybe I should try your way as it lets the designer really do what he
wants without any limitations set by my limited imagination in HTML layout! In fact, you've already proved it works....

He then passed this template over to me where I could sprinkle conditions, iterations, and insertions over it using eRuby blocks. Many times, the code that needed to be in the template files were too complicated, so that was split into helpers.

Now, when this sprinkling was done, I passed the template back to the HTML guy. And considering that all the scriplets were pretty much self-explanatory:

  <% for post in @posts %>
    <%= post.title %>
  <% end %>

and..

  <% if @person.authenticated? %>
    Hi, Mr. <%= @person.name %>
  <% end %>

The more examples I see, the more I think it's very similar.
For example:

<cgikit name="AuthenticatedCond">
  Hi, Mr. <cgikit name="PersonName"/>
</cgikit>

I'm just more comfortable with no reference to internal code data in the template.
And as we work on a xml-like file, I'm not shocked by the fact that we work with tags.

Raph

44

Florian Weber wrote:

The designer is there for that I guess.
I tell him, "hey, the structure of the address has changed. Replace the cgikit
address by 2 tags address1 and address2. Those are just strings". And he know he just has to add <cgikit name="address1"/> and <cgikit name="address1"/> where he sees fit.
Again, he doesn't care of the name of my variable eg.

same thing in rails. you just tell her/him to use @person.address1 and @
person.adress2 =)

I didn't mean it's easier with cgikit, I thought you suggested it was more
difficult in cgikit :wink:

But in your example, if I change my variable name, I have to change the template, as with cgikit, I just have to change the binding, which is a much smaller and
simpler file than the template.

Anyway, we've come to a point where we discuss really minor things. I'll test
Rails to get a better idea of how I can limit my code in the template, and
I encourage you to test cgikit, if only to confirm your opinion on the <cgikit> tags :wink:

Raph

45

David Heinemeier Hansson wrote:

What the HTML guy didn't do was the initial logic. The reason for is that this logic changed from page to page. The listing for Milestones wouldn't use the same methods as would the Todo lists and so on.

And the HTML guy couldn't really make any new templates in isolation anyway. You need some kind of controller action pulling the right things out of the database and so on before you pass on to the template. The

A very important point here... I have run into "designers" who had absolutely no concept of dynamic pages and databases. This is the type of person that would not understand the ruby code in a template. If it doesn't look like html, they don't understand it. It's questionable whether they'd understand cgkit's way of doing it either. If they saw

"Hi, Mr. Morton" in a web browser, they couldn't figure out where the "Morton" came from, even when looking at the following. :frowning:

     Hi, Mr. <%= @person.name %>

I personally wouldn't choose to work with such a designer... If they can't understand and learn some basic patterns related to dynamic page generation, it makes it very hard to work with them. They don't have to learn all of ruby, but it should be obvious that the above line outputs a name of some sort. Again, they don't work in isolation... the designer should be able to approach the coder with questions, and learn from those questions. (and vice versa)

<%= @person.name %>

It's very easy to copy and paste elsewhere, and more readable as dynamic content than <someHtmlTag value="something">
or <something:else @@some.wierd.java.thing class="something" param="else"> that make me look up another file somewhere to see what it does, which may then lead me to a properties file that leads me to yet another file.

(Yes, I'm frustrated with trying to learn J2EE right now.) :frowning: I much prefer this rails syntax, which is similar to how I did things in a perl ASP format. Looks good so far, David!

···

--
David Morton

46

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

···

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

47

I think I have some perspective on this considering that Basecamp was built using Rails with a separate HTML/design guy and separate programmer. The way that we worked, the HTML-guy prepare a template with just HTML.

I usually work the other way around: I make a first draft template, and the designer
enhance it. Maybe I should try your way as it lets the designer really do what he
wants without any limitations set by my limited imagination in HTML layout! In fact, you've already proved it works....

I think this is key. You want unbounded creativity for as long as possible. And if you already chosen to implement something with checkboxes, it's really not that easy to go some other route entirely.

···

--
David Heinemeier Hansson,
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.instiki.org/ -- A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ -- Web-based Project Management
http://www.loudthinking.com/ -- Broadcasting Brain
http://www.nextangle.com/ -- Development & Consulting Services

48

But in your example, if I change my variable name, I have to change the template, as with cgikit, I just have to change the binding, which is a much smaller and
simpler file than the template.

well, but if you replace the 'address' variable with 'address1' and 'address2'
in your ruby code, you will have to change the binding AND the template.

Anyway, we've come to a point where we discuss really minor things. I'll test
Rails to get a better idea of how I can limit my code in the template, and
I encourage you to test cgikit, if only to confirm your opinion on the <cgikit> tags :wink:

great! i think trying things out, especially with real life projects is always
the best thing..

i never tried cgikit i have to admit, but i used something somewhat similar for a couple
of projects:
http://wact.sourceforge.net/

basically i had the same concerns there and really started to curse every time i was
forced to do something programming like in xml.. (yes, i even had worse programming
in xml experiences. i did quite a bit of work in xslt =)

i admit that neither of the two options (ruby in the template or pure xml-template) is
the perfect solution for every project. it all depends on whats important for you and
what your requirements are.

49

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

50

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

···

Kirk Haines <khaines@enigo.com> wrote:

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"/>