rubyonrails and cgikit comparison

[gabriele renzi]

il Mon, 26 Jul 2004 03:48:30 +0900, Florian Weber

why shouldnt we have a real programming language in the template?

what if the presentation logic in our template is very very complicated?
just moving the complicated presentation logic out of the template into
another part like a binding or a ruby class doesnt change anything. its
just a form of indirection..

I think you're missing Raphael's point: he's not talking about

<condition name='foo'>
<b>ok</b>
</condition>

vs

%if foo
<b>ok</b>
%end

He's saying that he does not want to have 'foo' referencing something
real (i.e. the parameters passed to the page) cause that adds coupling
beetween the view logic and the business logic.

He just prefers to have that level of indirection where he can have
'foo' as a placeholder for, say, a 'show=true' passed to the page or a
Time.now==XMas_day or a sql query result.
You don't like that level of indirection and it's ok (I think I
agree), but it's not really a question of presentation logic in
template languages or in real programming languages.

 

[Bauduin Raphael]

Florian Weber wrote:

[snip]

<a href="foo" style="color: <%= (@some_stuff > 3) ? 'red' : 'black'
%>">foo</a>

how would you do this in xml?

My opinion:
-I would work with css
-The designer should not be concerned on the conditions to have one or
the other color. He designs a red class, and a black, and the code
determines which is used.

ex:
#template
<cgikit name="mylink"/>

#binding
mylink : CKHyperlink
{
href="foo"
class = link_class
}


#ruby code

#this file contains REDLIMIT value used throughout the appplitation
require "myparameters"

if @some_stuff < REDLIMIT
@link_class = "redcss"
else
@link_class = "blackcss"


And you have the benefit that you can use parameters like REDLIMIT
defined in a file required in the code, and used through the whole
application (though I guess the same applies to Rails if you require the
file in the component's code).

From our discussion, it seems you prefer to have a bit of code in the
template, but I prefer to have a bit of presentation logic in the code.
My fear it that the code in the template could become too important.

I also think it's much easier for a programmer to give a certain class
attribute to an element, based on conditions in his code, than for a
designer to enter the conditions to use a class or another. Giving a css
class doesn't get you inside the css, working with variables in the
template gets you inside the code.



Raph

 

[Bauduin Raphael]

il Mon, 26 Jul 2004 03:48:30 +0900, Florian Weber




I think you're missing Raphael's point: he's not talking about

<condition name='foo'>
<b>ok</b>
</condition>

vs

%if foo
<b>ok</b>
%end

He's saying that he does not want to have 'foo' referencing something
real (i.e. the parameters passed to the page) cause that adds coupling
beetween the view logic and the business logic.

You expressed my idea better than I did!
My concern is also that foo could become a lot of code which should not
be in the template.

Raph

 

[James Britt]

not really.

<a href="foo" style="color: <%= (@some_stuff > 3) ? 'red' : 'black'
%>">foo</a>

how would you do this in xml?

Replace the stuff that makes XML parsers unhappy.

<a href="foo"
style="color: &lt;%= (@some_stuff &gt; 3) ?
'red' : 'black' %&gt; " >foo</a>


It's fugly, though most templating formats have that problem anyway.

Most of them force a mix of disharmonious markup: not XML, not HTML, not
anything consistent with the document markup. If your main focus is on
the (X)HTML, and you try to use a fairly conventional HTML or XML
editor, the <%template sqiggles%> just get in the way.

In the above example, since the XML is just a way of structuring
the data (i.e., there are no elements that have special meaning to some
other process, other than a web browser), one could do this

<?EXP (@some_stuff > 3) ? 'red' : 'black' ?>
<a href="foo" style="color: EXP " >foo</a>

on the assumption that some process knows that when it find a PI, it
replaces that next occurence of the PI target (here 'EXP') with the
eval'ed results of the PI data.

It makes it a bit more friendly to designers and editing tools.

My particular preference for templating tools is something that lets me
check the validity of code and markup independent of each other
(knowing, of course, that the combined results must also at some point
be checked). I'd rather not have to "compile" a page each time I want
to verify that HTML attributes are properly quoted, or that there are no
syntax errors in the code.

James

 

[Kirk Haines]

On Mon, 26 Jul 2004 05:34:03 +0900, Florian Weber wrote

<a href="foo" style="color: <%= (@some_stuff > 3) ? 'red' : 'black'
%>">foo</a>

how would you do this in xml?

I'm finding this discussion fascinating as a discussion of different
approaches to solving a problem. This particular example intrigued me a bit
as while I personally don't like the above sort of mixing of code into HTML,
I also found that the CGIKit method of dealing with this that Raphael posted
to be more a more roundabout solution that I like, as well.

Here's Iowa's take on the above:

HTML file:

<a href="foo" style="color: @linkcolor">foo</a>


Code file:

def linkcolor
@some_stuff > 3 ? 'red' : 'black'
end


Now, my approach to this would, if I were planning ahead, would probably be
to use a CSS class instead of setting the style directly. That way all I
really end up doing is toggling between two different class names, and I let
the decision on what effect that has on the link's appearance be determined
in the stylesheet.

HTML:

<a href="foo" class="@linkclass">foo</a>


Code:

def linkclass
@some_stuff > 3 ? 'link_error' : 'link_normal'
end


CSS:

link_error {color: red}
link_normal {color: black}


Either way we are calling a piece of code from the HTML, but the code is not
actually embedded in there. If one is working in the designer/developer
segregation model, one can either not let the designers write any code at
all with this seperation, or if one trusts one's designers to write code
like linkclass() themselves, one could structure the code so that while the
main code file is the repository for the business logic for the page, and is
the domain of the developer, it require's a seperate code file that the
designers can use that contains presentation logic that will be used in the
template. Something like:


class MyPage < Iowa::Component

require 'MyPage_layout.rb' # This is the presentation logic file

# Everything else is business logic for the page.
# .
# .
# .
end


Anyway, glad to see your Rails release come to fruition, David. Keep up the
good discussions. They are very interesting.


Kirk Haines

 

[Florian Weber]

-I would work with css

-The designer should not be concerned on the conditions to have one or
the other color. He designs a red class, and a black, and the code
determines which is used.

sure. css classes would have been better, i just wanted to
keep it as simple as possible =)

ex:
#template
<cgikit name="mylink"/>

#binding
mylink : CKHyperlink
{
href="foo"
class = link_class
}


#ruby code

#this file contains REDLIMIT value used throughout the appplitation
require "myparameters"

if @some_stuff < REDLIMIT
@link_class = "redcss"
else
@link_class = "blackcss"

the problem with that is that you're app all of the sudden knows
something
about css. you have presentation logic in your application layer. imho
thats
horrible : /

From our discussion, it seems you prefer to have a bit of code in the
template, but I prefer to have a bit of presentation logic in the
code.
My fear it that the code in the template could become too important.

i'm okay with code doing presentation logic yup. like gabriele mentioned
earlier, i think the difference is that you prefer the indirection of
not referencing
data directly, while i'm okay with it and like not to have the overhead
of a
abstraction and indirection there..

I also think it's much easier for a programmer to give a certain class
attribute to an element, based on conditions in his code, than for a
designer to enter the conditions to use a class or another. Giving a
css class doesn't get you inside the css, working with variables in
the template gets you inside the code.

giving a css class gets you inside the presentation code. what if the
designer/html
guy needs to rename the class for some reason?

 

[Florian Weber]

Replace the stuff that makes XML parsers unhappy.

<a href="foo"
style="color: &lt;%= (@some_stuff &gt; 3) ?
'red' : 'black' %&gt; " >foo</a>

i meant how to describe the condition in a xml template language, not
how to escape the stuff in xml =)

 

[Florian Weber]

hi kirk!

basically i see the same problem in your first example. you have
presentation logic (knowing about css) in your application layer.
i like the idea of having a special file with such stuff
('MyPage_layout.rb')
though. thats basically how you can do it in rails also. you can just
define a little view helper file where you can define such methods,
so you dont have to do really dirty stuff in the eruby file directly.

basically i think the problem is:

at some point presentation logic (which css class to use) and business
data (not business logic!) meet (is @some_stuff > 3).

cgikits approach is to access the business data in the application
layer,
to calculate more complicatied presentation logic with it there and to
simple provide a way to pick up that presentation logic from the view.
basically without ever referencing directly to the business data..

i think the difference with rails is that its allowed to access
business data
directly from within the template. the thing is though: you can, you
dont
have to..

you could also do stuff like:

<a href="foo" style="color: @linkcolor">foo</a>

you can just use a little template helper method to define the
@linkcolor
property..


i'm very interested in other approaches though. like i said, i'm highly
sceptical about pure-xml views. i think its often overseen that views
can be complex and have complicated business logic in them. but just
because one part of the view is xhtml, doesnt mean that we also have to
use xml for parts where real programming languages would be much better.
i mean after all there is also stuff like javascript..

like i said though, im very interested in other approaches. especially
one of
the different link color based on different business data problem,
solved with
a xml templating language using conditions..

 

[Florian Weber]

He's saying that he does not want to have 'foo' referencing something

real (i.e. the parameters passed to the page) cause that adds coupling
beetween the view logic and the business logic.

i guess it all depends on what you prefer. the business data and the
view will always be coupled more or less. if you like the abstraction
of having some mediator/binding/etc or wanna do it directly..

the question is though: if the person who does the templates is the
same person who does the rest of the (ruby) coding, what do you gain
by the indirection of bindings/etc?

 

[Raphael Bauduin]

i guess it all depends on what you prefer. the business data and the
view will always be coupled more or less. if you like the abstraction
of having some mediator/binding/etc or wanna do it directly..

the question is though: if the person who does the templates is the
same person who does the rest of the (ruby) coding, what do you gain
by the indirection of bindings/etc?

When I work with a designer, I design a _very_ basic template,
and let the designer do the layout and all the work on the template.
And the designer doesn't have to deal with values coming from my code, he
doesn't care, and shouldn't.

So whatever I code, I won't break his layout. And whatever he does on the template,
he won't break the code. Very reassuring in both ways!

And this could help debugging too, as if my text doesn't appear in red after he changed
the template, I know it's not because he accidentally erased the condition as it is not
in the template.

Raph

 

[Florian Weber]

When I work with a designer, I design a _very_ basic template, and let
the designer do the layout and all the work on the template. And the
designer doesn't have to deal with values coming from my code, he
doesn't care, and shouldn't.
So whatever I code, I won't break his layout. And whatever he does on
the template, he won't break the code. Very reassuring in both ways!

but what for example if the attribute of a item in a repitition gets
renamed.
for example you decide replace the single 'address' attribute in your
ruby object to 'address1' and 'address2'. you will most likely also
change
your binding file to represent those changes.. then the designer will
also
have to change the template file..

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

 

[Raphael Bauduin]

but what for example if the attribute of a item in a repitition gets
renamed.
for example you decide replace the single 'address' attribute in your
ruby object to 'address1' and 'address2'. you will most likely also change
your binding file to represent those changes.. then the designer will also
have to change the template file..

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

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
other part's work, like mentioned in my previous mail)




Raph

 

[David Heinemeier Hansson]

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

It was very easy for the HTML guy to move that stuff around. Put more
things into the authenticated? block, move the scriptlets up and down.

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 HTML guy were never going to do those methods, so the
benefit of having him be able to do the initial sprinkling on his own
was pretty insignificant -- in our case, anyway.

Hopefully this serves as a clarification for what Rails is comfortable
having designers and programmers do.
--
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

 

[Raphael Bauduin]

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

 

[Florian Weber]

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

 

[Raphael Bauduin]

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 ;-)

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 ;-)


Raph

 

[David Heinemeier Hansson]

I think I have some perspective on this considering that Basecamp was

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

 

[Florian Weber]

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 ;-)

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.

 

[David Morton]

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.

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.) I much
prefer this rails syntax, which is similar to how I did things in a perl
ASP format. Looks good so far, David!

 

[Avi Bryant]

why shouldnt we have a real programming language in the template?

what if the presentation logic in our template is very very complicated?

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.

Of course, you still need to separate presentation from content - but
these days, HTML isn't supposed to be presentational, it's supposed to
be semantic. HTML *is* content, and as such should be firmly under
the control of the developer. The correct way of doing presentation
is through CSS, and the necessary indirections are already built in to
the CSS/HTML interaction so that you don't need templating at all.
This makes it a natural developer/designer boundary - just agree on
the CSS classes and ids, and work on your separate files.

For more in this vein, see
http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3257728961
..

Avi