Rubyonrails and cgikit comparison

ruby-talk
21

So the EmployeesHelper is basically just a preconfigured version of the generic table. And in the template you'd just have:
  <h2>Employee payroll</h2>
  <%= payroll_table(@payroll) %>
That's pretty clean to me.

That just leaves the reuse of a binding in several places in the template as unanswered.

By binding, do you mean @payroll? If you don't want that left to the template, just include it in the helper method. So you would use:

     def payroll_table(additional_options = {})
       options = DEFAULT_OPTIONS_FOR_PAYROLL_TABLE.merge(additional_options)
       table(@payroll, options)
     end

Notice that you can reference all the variables available to the template in the helpers. Now you're down to:

   <%= payroll_table %>

···

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

22

totally simple with rails. you can just write a little helper method for for links.
david already did some nice stuff like this to allow for example:
<%= link_to "some link", :action => "foo", :params => { "var1" => "val1", "var2" => "val2"} %>

But if you need several times the same link in a page, don't you put all this several times in the template? What if "var2" => "val2" should be replaced by "var2" => "val3" for each link? Do you edit each <%= link_to .... %> ?

also very simple. just create a little helper method. then you can do

<%= product_link({"var2" => "var3"}) %>

http://localhost/pages/foo?var1=val1&var2=val2
for sure you can also pass additional html options to the link_to helper method..
the thing you described earlier could be easily done with a little helper method
also.. same thing, just less indirection..

with cgikit for example you must know whats going on below the template, how
would you know otherwise which properties you can use for the repetition item, how
its named, etc?

I don't understand what you mean here. You don't specify the repetition item in the template, so no need to know it to design the template. You need it of course for the binding.

well, but you need to know the the properties of the items when you wanna
display them on the page, no?

When you use a variable you need to know the way to access it too.... I'm afraid I still don't get your point.

its often said that some templating languages which dont use programming
languages and have things like tags to define conditions, loops, etc are great
because designer/html-people can just use them easily and dont need to
know a programming language..

however that totally ignores that those designers/html-people still need
to know which variables/properties exists for the item they are working on..

for simple views something like xml might work okay. but for more complex stuff
it becomes very tricky, sometimes even impossible. you need something like
a 'programming language'. Use Of Xml

I must admit I haven't build a very complex website with cgikit (yet?), but from my experience in building a bigger site, I didn't see anything blocking in cgikit. To the contrary, I found it very clear and structured. You don't build your website in xml, you have a template that is HTML with <cgikit> tags that are replaced by html.

to me the cgikit templates look pretty much like (x)html + xml..

I thought you were afraid of all side technologies of XML. Of course if you can't see any xml combined with (x)html, there's no point to argue.....

not sure if i understand what you mean with that? could you explain further, please..

im definally not afraid of xml though. xhtml is great and xml also. just not for everything.
especially not for tasks where a programming language would be just so much easier
and better.

23

David Heinemeier Hansson wrote:

So the EmployeesHelper is basically just a preconfigured version of the generic table. And in the template you'd just have:
  <h2>Employee payroll</h2>
  <%= payroll_table(@payroll) %>
That's pretty clean to me.

That just leaves the reuse of a binding in several places in the template as unanswered.

By binding, do you mean @payroll? If you don't want that left to the template, just include it in the helper method. So you would use:

    def payroll_table(additional_options = {})
      options = DEFAULT_OPTIONS_FOR_PAYROLL_TABLE.merge(additional_options)
      table(@payroll, options)
    end

Notice that you can reference all the variables available to the template in the helpers. Now you're down to:

  <%= payroll_table %>

OK, I'll try to develop a component for rails to see by myself.

Thanks for your explanations.

Raph

···

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

24

Florian Weber wrote:

totally simple with rails. you can just write a little helper method for for links.
david already did some nice stuff like this to allow for example:
<%= link_to "some link", :action => "foo", :params => { "var1" => "val1", "var2" => "val2"} %>

But if you need several times the same link in a page, don't you put all this several times in the template? What if "var2" => "val2" should be replaced by "var2" => "val3" for each link? Do you edit each <%= link_to .... %> ?

also very simple. just create a little helper method. then you can do

<%= product_link({"var2" => "var3"}) %>

http://localhost/pages/foo?var1=val1&var2=val2
for sure you can also pass additional html options to the link_to helper method..
the thing you described earlier could be easily done with a little helper method
also.. same thing, just less indirection..

with cgikit for example you must know whats going on below the template, how
would you know otherwise which properties you can use for the repetition item, how
its named, etc?

I don't understand what you mean here. You don't specify the repetition item in the template, so no need to know it to design the template. You need it of course for the binding.

well, but you need to know the the properties of the items when you wanna
display them on the page, no?

When you use a variable you need to know the way to access it too.... I'm afraid I still don't get your point.

its often said that some templating languages which dont use programming
languages and have things like tags to define conditions, loops, etc are great
because designer/html-people can just use them easily and dont need to
know a programming language..

however that totally ignores that those designers/html-people still need
to know which variables/properties exists for the item they are working on..

Let's take a concrete example. I have developed a CKHTMLTable component, displaying database rows in a table. The designer can work on the template of this component to set it up, although this should mostly mean design a css.

When the component is used, there's no need to set it up anymore. Of course, the designer should know this component displays a table, and not a link. But that's the same in Rails if you work with components.

But I got your point, and if the programmer doesn't talk with the designer there could be a problem. But that's the downside of using components: the designer has to know what this component is.

for simple views something like xml might work okay. but for more complex stuff
it becomes very tricky, sometimes even impossible. you need something like
a 'programming language'. UseOfXml

I must admit I haven't build a very complex website with cgikit (yet?), but from my experience in building a bigger site, I didn't see anything blocking in cgikit. To the contrary, I found it very clear and structured. You don't build your website in xml, you have a template that is HTML with <cgikit> tags that are replaced by html.

to me the cgikit templates look pretty much like (x)html + xml..

I thought you were afraid of all side technologies of XML. Of course if you can't see any xml combined with (x)html, there's no point to argue.....

not sure if i understand what you mean with that? could you explain further, please..

Hmm, not sure the english I wrote is correct. I was just meaning that it could come down to you having different preferences than me.

im definally not afraid of xml though. xhtml is great and xml also. just not for everything.
especially not for tasks where a programming language would be just so much easier
and better.

That's just the point we disagree on. I don't think we should have
real programming in the template(like references to variables), some basic logic only. In short, I like the presence of the binding, you don't. That's ok with me :wink:

Anyway, thanks for this exchange of opinions.

Raph

···
25

That's just the point we disagree on. I don't think we should have
real programming in the template(like references to variables), some basic logic only. In short, I like the presence of the binding, you don't. That's ok with me :wink:

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

26

OK, I'll try to develop a component for rails to see by myself.

Thanks for your explanations.

Excellent! If you were to make a TableHelper, I'm sure it would find its way into a coming release of Action Pack. I'd love to be able to automate that. Even if it's not applicable in all cases (like the lure of automated form building).

Thanks for being critical and pushing back.

···

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

27

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.

···

il Mon, 26 Jul 2004 03:48:30 +0900, Florian Weber <csshsh@structbench.com> ha scritto::

That's just the point we disagree on. I don't think we should have
real programming in the template(like references to variables), some
basic logic only. In short, I like the presence of the binding, you
don't. That's ok with me :wink:

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

28

Florian Weber <csshsh@structbench.com> wrote in message news:<34E7BB04-DE6B-11D8-8F52-000A95BD142E@structbench.com>...

> That's just the point we disagree on. I don't think we should have
> real programming in the template(like references to variables), some
> basic logic only. In short, I like the presence of the binding, you
> don't. That's ok with me :wink:

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

29

gabriele renzi wrote:

That's just the point we disagree on. I don't think we should have
real programming in the template(like references to variables), some basic logic only. In short, I like the presence of the binding, you don't. That's ok with me :wink:

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.

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

Raph

···

il Mon, 26 Jul 2004 03:48:30 +0900, Florian Weber > <csshsh@structbench.com> ha scritto::

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.

30

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?

31

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

···

Avi Bryant <avi@beta4.com> wrote:

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.

32

Florian Weber wrote:

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?

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

···
33

Martin, take a look at Borges.

http://borges.rubyforge.org

Kirk Haines

···

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

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

34

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?

···

On Jul 26, 2004, at 12:56 Uhr, Raphael Bauduin wrote:

Florian Weber wrote:

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?

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!

35

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

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

36

Florian Weber wrote:

Florian Weber wrote:

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?

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

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.

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

···

On Jul 26, 2004, at 12:56 Uhr, Raphael Bauduin wrote:

37

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

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

···

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

38

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

···

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.

39

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

40

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