Rubyonrails and cgikit comparison

There seems to be a lot of excitement about rubyonrails even before the announcement of version 0.5.

What makes rubyonrails 0.5 more attractive than cgikit 1.2.1? I'm under the impression cgikit offers MVC and has an architecture similar to WebObjects (which is well-regarded) but I've no experience with these tools.

Thanks.

cgikit
http://www.spice-of-life.net/cgikit/index_en.html

rubyonrails

i think following things make rails much more attractive:

- rails is much more than just a mvc framework: +activerecord.

- cgikit seems to have way more overhead that rails. i mean, just
compare a simple hello world. i admit its kinda silly to compare
frameworks via the most simple hello world, that doesnt show
their real power. but i've used frameworks which are similiar
to cgikit before.. and believe me, it can turn into a pure nightmare
when you have to create components for the smallest little
things.

i really believe into using ruby as a view language. the whole
'every view can be described in xml'-thing is totally utopian and
will never be happening. sooner or later you run into situations
where things become terrible akward. what for example if you
wanna change the style attribute of a xhtml tag based on some
condition?

- rails is pragmatic. it makes simple things simple, and hard
things possible (yes! i bet you never heard this sentence
before ; ) but with rails its totally true. if you believe in components
in the view, its possible to add that..

basically you really start to appreciate that you dont have to
write tons of config files for everything. cgikit could also do that.
it would be so much nicer if there would be some name specifications
for your component class. like naming methods which return attributes
in a special way. then you could get rid of the whole binding file. (i
might be wrong, since i just quickly browsed the docs =)

ciao!
florian

···

On Jul 25, 2004, at 10:51 Uhr, Gully Foyle wrote:

There seems to be a lot of excitement about rubyonrails even before the announcement of version 0.5.

What makes rubyonrails 0.5 more attractive than cgikit 1.2.1? I'm under the impression cgikit offers MVC and has an architecture similar to WebObjects (which is well-regarded) but I've no experience with these tools.

Gully Foyle wrote:

There seems to be a lot of excitement about rubyonrails even before the announcement of version 0.5.

What makes rubyonrails 0.5 more attractive than cgikit 1.2.1? I'm under the impression cgikit offers MVC and has an architecture similar to WebObjects (which is well-regarded) but I've no experience with these tools.

I'm using cgikit and starting to look at its code. What I like about it is that it completely separates presentation from code (more so than rails by reading nextangle.com, see below).

For example, if you want to repeat something your html page, you can use the CKRepetition element like this in your template file:

<cgikit name="myrepetition">
  <!-- CONTENT TO BE REPEATED -->
</cgikit>

Note that you don't enter any reference to the data you work on, you simply specify an cgikit element named "my repetition". You don't even say which type of element "myrepetition" is. You do that in the binding file:

myrepetition : CKRepetition
{
     list = my_items_list;
     item = current_item;
}

where my_items_list is an array in your code (which is a class extending CKComponent). When iterating, you can access the current element with current_item.

For example, if my_items_list= ["first","second","third"], and you want to display them as an <UL>, you can do it this way:

#template
<ul>
   <cgikit name="myrepetition">
     <li>
        <cgikit name="listitem"/>
     </li>
   </cgikit>
</ul>

#binding
myrepetition : CKRepetition
{
     list = my_items_list;
     item = current_item;
}
listitem : CKString
{
     value=current_item;
}

You ruby code can be as simple as that:
#code
class CSSList < CKComponent
   def pre_action
     @my_items_list = ["first","second","third"]
   end
end

The reason I said it seems cgikit better separates presentation and logc, is that in nextangle.com, I saw this code:

<% for comment in @post.comments %>
    <li> <%= comment.value%> </li>
<% end %>

This may be a question of personal taste, but I really prefer the cgikit solution where there's absolutely no reference in the template to the data we're working on. Now, this opinion is only based on reading the pdf available on rails at the url mentioned. Can someone correct me or
give another opinion on the subject?

The other thing I really like with cgikit is that you can develop completely reusable components. My first developments with cgikit resulted in a CKHTMLTable component I reuse a lot to display data in
html tables (see http://www.raphinou.com/wiki/wiki/show/CKHTMLTable+Details\)

Cgikit is not perfect though, as components reuse could be better (that's why I'm looking at the source actually), but I think it'll stay
my development platform of choice, certainly combined with Active Record.

Raph

···

Thanks.

cgikit
CGIKit

rubyonrails
http://www.rubyonrails.org/

The reason I said it seems cgikit better separates presentation and logc, is that in nextangle.com, I saw this code:

<% for comment in @post.comments %>
   <li> <%= comment.value%> </li>
<% end %>

This may be a question of personal taste, but I really prefer the cgikit solution where there's absolutely no reference in the template to the data we're working on. Now, this opinion is only based on reading the pdf available on rails at the url mentioned. Can someone correct me or
give another opinion on the subject?

you have a reference to the data you are working on. "myrepetition". the only difference
is thate you have a bridge with the binding file. in the template you only refer to the binding
file and the binding file refers to the 'real' data.

i have to admit i dont really see the advantage of it. why the overhead of the binding
file? for sure there is the good old 'designers/html-people can edit templates' without having to
worry about the programming under the hood. but isnt it so much simpler to learn some
basic ruby constructs instead of yet another template language, where sooner
or later you run into problems/limitations.

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?

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

for sure you can extract everything even remotely complex/programming language
like into components. but thats such a overhead. for sure at first you might think 'well,
i might be able to reuse component later on'. but how can you know? it certainly
doesnt apply for every situation. so yagni really applies here..

i hope i dont come across to mean with cgikit. i think its a good think. i just made
some really frustrating experiences with xml templating systems, so im kinda bitter
about it =)

What I like about it is that it completely separates presentation from code...

In my opinion, the important part of separating presentation from "the rest" is not doing away with code. I find that somewhat misleading anyway, as both Java Taglibs and the CGIKit approach still uses loops and variables. A rose by any other name...

So the important separation is one of responsibility. The view should only be responsible for presenting the work of others. Whether that's done through loops that look like tags or loop that looks like Ruby code doesn't seem to matter too much. (Well, actually, I'm of the opinion that it does matter in the sense that Ruby is a much better templating language than most templating languages).

The reason I said it seems cgikit better separates presentation and logc, is that in nextangle.com, I saw this code:

<% for comment in @post.comments %>
   <li> <%= comment.value%> </li>
<% end %>

This may be a question of personal taste, but I really prefer the cgikit solution where there's absolutely no reference in the template to the data we're working on.

My knowledge of CGIKit is shallow, but doesn't the name attribute on the cgikit tag amount to a reference? When you say:

   <cgikit name="myrepetition">

That references a binding, which then specifies some names for my_items_list and the item. My simple mind is already dizzy from the indirection that's going on for something as simple as a loop. But that's probably just me.

Now, this opinion is only based on reading the pdf available on rails at the url mentioned. Can someone correct me or give another opinion on the subject?

That is indeed correct. The view will expect that there is an object available as an instance variable called post, which responds to "comments" which in turn responds to "each". There is no requirement that this post object be of a certain class or that this view is rendered by a specific action.

So I guess I'm just trying to understand what the indirection buys me. Will it make the CGIKit templates more reusable in other actions? Is it easier to read and understand to some?

The other thing I really like with cgikit is that you can develop completely reusable components. My first developments with cgikit resulted in a CKHTMLTable component I reuse a lot to display data in html tables (see http://www.raphinou.com/wiki/wiki/show/CKHTMLTable+Details\)

Reusable view components is a subject dear to the heart of Rails. Which is why the framework urges you to move this kind of code into what's called Helpers. When you create a new controller, a new helper is automatically created to serve the specific needs of that controller. And on top of that, Action Pack ships with six default helpers (http://ap.rubyonrails.org/classes/ActionView/Helpers.html\) to make the creation of forms, urls, and text manipulation an easy deal.

Cgikit is not perfect though, as components reuse could be better (that's why I'm looking at the source actually), but I think it'll stay
my development platform of choice, certainly combined with Active Record.

I'm glad to see that the components of Rails find usage outside of Rails! The Action Pack setup is just one way to do templating and control flow, it's surely not the only one.

···

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

There seems to be a lot of excitement about rubyonrails even before
the announcement of version 0.5.

What makes rubyonrails 0.5 more attractive than cgikit 1.2.1? I'm
under the impression cgikit offers MVC and has an architecture similar
to WebObjects (which is well-regarded) but I've no experience with
these tools.

It's a bit weird for me to advocate CGIKit, as I am developing a competing
framework (SWS/SDS), but I'll try to avoid bias :slight_smile:

i think following things make rails much more attractive:

- rails is much more than just a mvc framework: +activerecord.

So is cgikit (together with tapkit).

- cgikit seems to have way more overhead that rails. i mean, just
compare a simple hello world. i admit its kinda silly to compare
frameworks via the most simple hello world, that doesnt show
their real power.

I agree with you - there is no point in comparing framework via the most
simple application (how simple it would be to write "hello world" as a
regular CGI script :).

but i've used frameworks which are similiar to cgikit before.. and
believe me, it can turn into a pure nightmare when you have to create
components for the smallest little things.

I also used frameworks that are similar to cgikit (mostly Java ones -
WebObjects, Tapestry) before and I find them very powerful for REAL LIFE
applications ("hello world" is NOT one). I disagree it is difficult to
create components for small things, if you have good dev tools. And
without decent dev tools even a very powerful framework will inevitably
turn into nightmare, when the application grows complicated enough.

i really believe into using ruby as a view language. the whole
'every view can be described in xml'-thing is totally utopian and
will never be happening. sooner or later you run into situations
where things become terrible akward. what for example if you
wanna change the style attribute of a xhtml tag based on some
condition?

And I don't like messing programming language with HTML, like rails do.
IMHO the perfect MVC framework should have pure HTML templates, so the
HTML & graphic guys could edit them not even knowing the framework or
underlying programming language. I admit cgikit is not very good at it
(as it introduces <cgikit> tag, mimicking WebObjects' <webobject> tag),
but eg. Tapestry is much better at this point (and SWS too, but Tapestry
is better - yet:).

As for your example - I hope you realize the example is awkward itself
:slight_smile: No matter which framework you choose, the solution will always be
complicated and ugly. And yes, you can do this in cgikit :slight_smile:

- rails is pragmatic. it makes simple things simple, and hard
things possible (yes! i bet you never heard this sentence
before ; ) but with rails its totally true. if you believe in components
in the view, its possible to add that..

I don't care if it makes simple things simple. In the company I work
for, we use WebObjects for complicated applications and simple Ruby
FastCGI scripts for simple ones. For simple things you don't need a MVC
framework, you can print the HTML code directly.

basically you really start to appreciate that you dont have to
write tons of config files for everything. cgikit could also do that.
it would be so much nicer if there would be some name specifications
for your component class. like naming methods which return attributes
in a special way. then you could get rid of the whole binding file. (i
might be wrong, since i just quickly browsed the docs =)

Yes, and then you would encounter the situation, when you REALLY can't
follow this convention (the same goes for O/R mapping frameworks and
mapping SQL columns to attributes of the same name - think about "ID"
and what "id" attribute is used for in Ruby :slight_smile: and you are stuck. I
really like the freedom of cgikit-like frameworks.

Disclaimer: I really didn't intend to bash rails, so if anyone gets an
impression I DID bash it, I apologize. IMHO rails got a bit overhyped
(sorry, but I don't care it is a 1KLOC framework - I could decrease the
size of any of my libraries, but at cost of code quality. I rather chose
to avoid eval and other evil constructs instead) and I just wanted to
point out there are other solutions at least as powerful and elegant as
rails.

···

On Sun, 25 Jul 2004 19:53:55 +0900, Florian Weber wrote:

--
Marek Janukowicz

Florian Weber wrote:

The reason I said it seems cgikit better separates presentation and logc, is that in nextangle.com, I saw this code:

<% for comment in @post.comments %>
   <li> <%= comment.value%> </li>
<% end %>

This may be a question of personal taste, but I really prefer the cgikit solution where there's absolutely no reference in the template to the data we're working on. Now, this opinion is only based on reading the pdf available on rails at the url mentioned. Can someone correct me or
give another opinion on the subject?

you have a reference to the data you are working on. "myrepetition". the only difference
is thate you have a bridge with the binding file. in the template you only refer to the binding
file and the binding file refers to the 'real' data.

i have to admit i dont really see the advantage of it. why the overhead of the binding
file? for sure there is the good old 'designers/html-people can edit templates' without having to
worry about the programming under the hood. but isnt it so much simpler to learn some
basic ruby constructs instead of yet another template language, where sooner
or later you run into problems/limitations.

I have to admit that in using cgikit I didn't experience the binding file as overhead. I find it really practical that, once my template is ok, I don't ever have to go back to it if I want to change something in my code. What do you mean by running into problems sooner or later?

One advantage I can see with the binding is that you can reuse your element in different places in the same pages, and if you change the binding definition, the changes are applied to all occurences in the page. For example a link.

#html
<!-- html header -->
<cgikit name="Link">
<!-- HTML -->
<!-- html footer -->
<cgikit name="Link">

#binding

Link : CKHyperlink
{
   href = "http://www.destpage.net";
   string = "Ruby Homepage";
   query = get_vars;
}

#ruby code
   @get_vars = [ { "var1" => "val1"} , {"var2" => "val2"} ]

This results in :
<a href="http://www.destpage.net?var1=val1&var2=val2&quot;&gt;Ruby Homepage</a>

in rails, I guess you can do it like

<a href="<%=myurlbuiltwithgetvars%>"><%=linktitle%></a>

But now, what it you forgot to set an attribute for it? Liek the css class to use?
With cgikit, I just add this in the binding:

  class="mycssclass";

and it's applied everywhare.

This adds the attribute to all instances. In rails I guess you have to edit all instances of the link. This is one example of why I personally prefer the cgikit way.

In rails, from my understandings, you would have to edit all the link instances, which would be less DRY oriented :wink:

(Correct me if there's a better way to do it in rails,I'm interested to know)

This could be applied to a image you put before each entry in a menu, or to a image you use as the header of a <li>.

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.

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.

for sure you can extract everything even remotely complex/programming language
like into components. but thats such a overhead. for sure at first you might think 'well,
i might be able to reuse component later on'. but how can you know? it certainly
doesnt apply for every situation. so yagni really applies here..

Well, I know of some components I could reuse and from my first attempt with cgikit, it worked very well. From there comes my enthousiasm for it :slight_smile:

i hope i dont come across to mean with cgikit. i think its a good think. i just made
some really frustrating experiences with xml templating systems, so im kinda bitter
about it =)

Having another opinion is not a problem for anybody I think (it's even very interesting), as long as the discussion is contructive (which it is now imho :wink:

Raph

···

David Heinemeier Hansson wrote:

What I like about it is that it completely separates presentation from code...

In my opinion, the important part of separating presentation from "the rest" is not doing away with code. I find that somewhat misleading anyway, as both Java Taglibs and the CGIKit approach still uses loops and variables. A rose by any other name...

So the important separation is one of responsibility. The view should only be responsible for presenting the work of others. Whether that's done through loops that look like tags or loop that looks like Ruby code doesn't seem to matter too much. (Well, actually, I'm of the opinion that it does matter in the sense that Ruby is a much better templating language than most templating languages).

The reason I said it seems cgikit better separates presentation and logc, is that in nextangle.com, I saw this code:

<% for comment in @post.comments %>
   <li> <%= comment.value%> </li>
<% end %>

This may be a question of personal taste, but I really prefer the cgikit solution where there's absolutely no reference in the template to the data we're working on.

My knowledge of CGIKit is shallow, but doesn't the name attribute on the cgikit tag amount to a reference? When you say:

  <cgikit name="myrepetition">

That references a binding, which then specifies some names for my_items_list and the item. My simple mind is already dizzy from the indirection that's going on for something as simple as a loop. But that's probably just me.

Now, this opinion is only based on reading the pdf available on rails at the url mentioned. Can someone correct me or give another opinion on the subject?

That is indeed correct. The view will expect that there is an object available as an instance variable called post, which responds to "comments" which in turn responds to "each". There is no requirement that this post object be of a certain class or that this view is rendered by a specific action.

So I guess I'm just trying to understand what the indirection buys me. Will it make the CGIKit templates more reusable in other actions? Is it easier to read and understand to some?

See my answer to Florian for an example where the indirection helps in the DRY direction (again if I'm correct in my asumptions about rails).

My point of view is also that the <cgikit> tags in the template will always be short, with only one attribute. On the other hand, in the binding, I can put as many attribute as I want.

<cgikit name="Example">

Example : CKMyExample
{
    list = items_list
    condition = displayed?
    filter = filter_expression
    even_rows_color = even_color
    odd_rows_color = odd_color
    max_rows = displayed_rows
    linked_fields = example_links
    hidden_fields = example_hidden
    message_empty = "No items in list"
    table_title = "My items"
    show_columns_headers = headers_shown?
    column_headers = field_names
}

This could result in a HTML table with title "My items" if displayed? is true, the table displays the items in items_list, but filtered with filter_expression. Even rows have background color even_color and odd rows have background color odd_color. The table displays a maximum of displayed_rows at a time. fields in example_links are displayed as links (example_links contains the definition of the links for each field) and fields in example_hidden are not showed. If no items are in the list, display "No items in list". If headers_shown? is true, heach column has a header with the name of the column taken from fields_names

In this example, my template file is kept really simple and readable, and all specs go in the binding file.

Wouldn't that result in a very long tag, and thus more difficult to read, in a Rails template?
I don't doubt you can make the same component, if you pass all arguments in the template, it become hard tom read the template. Maybe you can pass all arguments in the code, but then you have to take the discipline to keep all the code in the same place. With bindings, you know exactly where you pass the arguments.

The other thing I really like with cgikit is that you can develop completely reusable components. My first developments with cgikit resulted in a CKHTMLTable component I reuse a lot to display data in html tables (see http://www.raphinou.com/wiki/wiki/show/CKHTMLTable+Details\)

Reusable view components is a subject dear to the heart of Rails. Which is why the framework urges you to move this kind of code into what's called Helpers. When you create a new controller, a new helper is automatically created to serve the specific needs of that controller. And on top of that, Action Pack ships with six default helpers (http://ap.rubyonrails.org/classes/ActionView/Helpers.html\) to make the creation of forms, urls, and text manipulation an easy deal.

I'll take a look at it!

Cgikit is not perfect though, as components reuse could be better (that's why I'm looking at the source actually), but I think it'll stay
my development platform of choice, certainly combined with Active Record.

I'm glad to see that the components of Rails find usage outside of Rails! The Action Pack setup is just one way to do templating and control flow, it's surely not the only one.

Of course! And I would find it great if my opinion and enthousiasm for cgikit could help Rails indirectly! :slight_smile:

Cheers.

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

I agree with you - there is no point in comparing framework via the most
simple application (how simple it would be to write "hello world" as a
regular CGI script :).

but i've used frameworks which are similiar to cgikit before.. and
believe me, it can turn into a pure nightmare when you have to create
components for the smallest little things.

I also used frameworks that are similar to cgikit (mostly Java ones -
WebObjects, Tapestry) before and I find them very powerful for REAL LIFE
applications ("hello world" is NOT one). I disagree it is difficult to
create components for small things, if you have good dev tools. And
without decent dev tools even a very powerful framework will inevitably
turn into nightmare, when the application grows complicated enough.

i didnt really mean that its difficult. its just a overhead. why would i want
to create a component for something im only going to use once? why
the abstraction and indirection? even when good dev tools save you
some time, it still costs more time than doing it directly and without the
abstraction..

i really believe into using ruby as a view language. the whole
'every view can be described in xml'-thing is totally utopian and
will never be happening. sooner or later you run into situations
where things become terrible akward. what for example if you
wanna change the style attribute of a xhtml tag based on some
condition?

And I don't like messing programming language with HTML, like rails do.
IMHO the perfect MVC framework should have pure HTML templates, so the
HTML & graphic guys could edit them not even knowing the framework or
underlying programming language. I admit cgikit is not very good at it
(as it introduces <cgikit> tag, mimicking WebObjects' <webobject> tag),
but eg. Tapestry is much better at this point (and SWS too, but Tapestry
is better - yet:).

like i mentioned in a earlier email, the dream of having html & graphic
people editing the templates without even knowing whats going on
under the hood is a dream which will never come true. sooner or later
they will have some stuff like conditions in their templates..

really check out the blog entry of martin fowler. he has some valid points.
also the guy who created ant admitted that it was a terrible idea to use xml
for the build files. xml just isnt made for anything even remotely related
to programming/conditions/etc..

As for your example - I hope you realize the example is awkward itself
:slight_smile: No matter which framework you choose, the solution will always be
complicated and ugly. And yes, you can do this in cgikit :slight_smile:

not really.

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

how would you do this in xml?

- rails is pragmatic. it makes simple things simple, and hard
things possible (yes! i bet you never heard this sentence
before ; ) but with rails its totally true. if you believe in components
in the view, its possible to add that..

I don't care if it makes simple things simple. In the company I work
for, we use WebObjects for complicated applications and simple Ruby
FastCGI scripts for simple ones. For simple things you don't need a MVC
framework, you can print the HTML code directly.

its not like there are only two existing types of app: simple and complicated
ones.. there are things in between..

basically you really start to appreciate that you dont have to
write tons of config files for everything. cgikit could also do that.
it would be so much nicer if there would be some name specifications
for your component class. like naming methods which return attributes
in a special way. then you could get rid of the whole binding file. (i
might be wrong, since i just quickly browsed the docs =)

Yes, and then you would encounter the situation, when you REALLY can't
follow this convention (the same goes for O/R mapping frameworks and
mapping SQL columns to attributes of the same name - think about "ID"
and what "id" attribute is used for in Ruby :slight_smile: and you are stuck. I
really like the freedom of cgikit-like frameworks.

personally i prefer to be forced to keep such limitations in mind and
use something different than 'id', but not being forced tell the lib
how to map every column to a attribute..

plus im pretty sure that it wouldnt be hard to add something to activerecord
which allows you to declare names for such exceptional attributes specifically..

Disclaimer: I really didn't intend to bash rails, so if anyone gets an
impression I DID bash it, I apologize. IMHO rails got a bit overhyped
(sorry, but I don't care it is a 1KLOC framework - I could decrease the
size of any of my libraries, but at cost of code quality. I rather chose
to avoid eval and other evil constructs instead) and I just wanted to
point out there are other solutions at least as powerful and elegant as
rails.

Now that it's out, it's actually a 2-KLOC framework :). And while I don't care much for neither the implication that the code quality of Rails suffers due its humble size (or use of evals) nor that it owes all attention to the fact, I do welcome the notion that there are other powerful and/or elegant frameworks out there. Only a fool would dispute that.

But then again, one man's elegance is another's clumsiness. And there's obviously a difference of vision (re: "the perfect MVC framework should have pure HTML templates"). Each his own. The more the merrier. And all that.

···

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

Wouldn't that result in a very long tag, and thus more difficult to read, in a Rails template?
I don't doubt you can make the same component, if you pass all arguments in the template, it become hard tom read the template. Maybe you can pass all arguments in the code, but then you have to take the discipline to keep all the code in the same place. With bindings, you know exactly where you pass the arguments.

You would use helpers for this stuff. So you could have a generic TableHelper and then have your specific EmployeesHelper:

   class TableHelper
     def table(source, options = {})
       # construct an HTML table based on the options
     end
   end

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

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.

···

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

I have to admit that in using cgikit I didn't experience the binding file as overhead. I find it really practical that, once my template is ok, I don't ever have to go back to it if I want to change something in my code. What do you mean by running into problems sooner or later?

with running into problems sooner or later i meant that sooner or later it
will get really annoying that you only have two choices: use xml to do
something very programming language like or to write components for
every tiny little special thing..

One advantage I can see with the binding is that you can reuse your element in different places in the same pages, and if you change the binding definition, the changes are applied to all occurences in the page. For example a link.

#html
<!-- html header -->
<cgikit name="Link">
<!-- HTML -->
<!-- html footer -->
<cgikit name="Link">

#binding

Link : CKHyperlink
{
  href = "http://www.destpage.net";
  string = "Ruby Homepage";
  query = get_vars;
}

#ruby code
  @get_vars = [ { "var1" => "val1"} , {"var2" => "val2"} ]

This results in :
<a href="http://www.destpage.net?var1=val1&var2=val2&quot;&gt;Ruby Homepage</a>

in rails, I guess you can do it like

<a href="<%=myurlbuiltwithgetvars%>"><%=linktitle%></a>

But now, what it you forgot to set an attribute for it? Liek the css class to use?
With cgikit, I just add this in the binding:

class="mycssclass";

and it's applied everywhare.

This adds the attribute to all instances. In rails I guess you have to edit all instances of the link. This is one example of why I personally prefer the cgikit way.

In rails, from my understandings, you would have to edit all the link instances, which would be less DRY oriented :wink:

(Correct me if there's a better way to do it in rails,I'm interested to know)

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"} %>

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?

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

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

···

- rails is pragmatic. it makes simple things simple, and hard
things possible (yes! i bet you never heard this sentence
before ; ) but with rails its totally true. if you believe in components
in the view, its possible to add that..

I don't care if it makes simple things simple. In the company I work
for, we use WebObjects for complicated applications and simple Ruby
FastCGI scripts for simple ones. For simple things you don't need a MVC
framework, you can print the HTML code directly.

its not like there are only two existing types of app: simple and complicated
ones.. there are things in between..

basically you really start to appreciate that you dont have to
write tons of config files for everything. cgikit could also do that.
it would be so much nicer if there would be some name specifications
for your component class. like naming methods which return attributes
in a special way. then you could get rid of the whole binding file. (i
might be wrong, since i just quickly browsed the docs =)

Yes, and then you would encounter the situation, when you REALLY can't
follow this convention (the same goes for O/R mapping frameworks and
mapping SQL columns to attributes of the same name - think about "ID"
and what "id" attribute is used for in Ruby :slight_smile: and you are stuck. I
really like the freedom of cgikit-like frameworks.

personally i prefer to be forced to keep such limitations in mind and
use something different than 'id', but not being forced tell the lib
how to map every column to a attribute..

plus im pretty sure that it wouldnt be hard to add something to activerecord
which allows you to declare names for such exceptional attributes specifically..

Florian Weber wrote:

As for your example - I hope you realize the example is awkward itself
:slight_smile: No matter which framework you choose, the solution will always be
complicated and ugly. And yes, you can do this in cgikit :slight_smile:

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

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

···

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?

Florian Weber wrote:

I have to admit that in using cgikit I didn't experience the binding file as overhead. I find it really practical that, once my template is ok, I don't ever have to go back to it if I want to change something in my code. What do you mean by running into problems sooner or later?

with running into problems sooner or later i meant that sooner or later it
will get really annoying that you only have two choices: use xml to do
something very programming language like or to write components for
every tiny little special thing..

One advantage I can see with the binding is that you can reuse your element in different places in the same pages, and if you change the binding definition, the changes are applied to all occurences in the page. For example a link.

#html
<!-- html header -->
<cgikit name="Link">
<!-- HTML -->
<!-- html footer -->
<cgikit name="Link">

#binding

Link : CKHyperlink
{
  href = "http://www.destpage.net";
  string = "Ruby Homepage";
  query = get_vars;
}

#ruby code
  @get_vars = [ { "var1" => "val1"} , {"var2" => "val2"} ]

This results in :
<a href="http://www.destpage.net?var1=val1&var2=val2&quot;&gt;Ruby Homepage</a>

in rails, I guess you can do it like

<a href="<%=myurlbuiltwithgetvars%>"><%=linktitle%></a>

But now, what it you forgot to set an attribute for it? Liek the css class to use?
With cgikit, I just add this in the binding:

class="mycssclass";

and it's applied everywhare.

This adds the attribute to all instances. In rails I guess you have to edit all instances of the link. This is one example of why I personally prefer the cgikit way.

In rails, from my understandings, you would have to edit all the link instances, which would be less DRY oriented :wink:

(Correct me if there's a better way to do it in rails,I'm interested to know)

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

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.

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

Raph

···

David Heinemeier Hansson wrote:

Wouldn't that result in a very long tag, and thus more difficult to read, in a Rails template?
I don't doubt you can make the same component, if you pass all arguments in the template, it become hard tom read the template. Maybe you can pass all arguments in the code, but then you have to take the discipline to keep all the code in the same place. With bindings, you know exactly where you pass the arguments.

You would use helpers for this stuff. So you could have a generic TableHelper and then have your specific EmployeesHelper:

  class TableHelper
    def table(source, options = {})
      # construct an HTML table based on the options
    end
  end

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

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.

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

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

As for your example - I hope you realize the example is awkward itself
:slight_smile: No matter which framework you choose, the solution will always be
complicated and ugly. And yes, you can do this in cgikit :slight_smile:

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>

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

···

On Jul 26, 2004, at 1:35 Uhr, James Britt wrote:

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

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

···

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