rubyonrails and cgikit comparison

[Gully Foyle]

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
http://www.rubyonrails.org/

 

[Florian Weber]

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

 

[Bauduin Raphael]

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 http://media.nextangle.com/rails/ror2bc.pdf, 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 http://media.nextangle.com/rails/ror2bc.pdf, 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

 

[Florian Weber]

The reason I said it seems cgikit better separates presentation and

logc, is that in http://media.nextangle.com/rails/ror2bc.pdf, 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'.
http://www.martinfowler.com/bliki/UseOfXml.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..

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

 

[David Heinemeier Hansson]

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 http://media.nextangle.com/rails/ror2bc.pdf, 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

 

[Bauduin Raphael]

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

(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

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'. http://www.martinfowler.com/bliki/UseOfXml.html

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

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

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



Raph

 

[Bauduin Raphael]

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



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.



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.

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!

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!

Cheers.

Raph

 

[David Heinemeier Hansson]

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

 

[Florian Weber]

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

(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", arams => { "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..

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?

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

 

[Bauduin Raphael]

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

(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", arams => { "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..





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.

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

 

[Bauduin Raphael]

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]

So the EmployeesHelper is basically just a preconfigured version of

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

 

[Florian Weber]

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

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

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.

 

[Bauduin Raphael]

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

 

[Bauduin Raphael]

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




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.

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

Anyway, thanks for this exchange of opinions.

Raph

 

[Florian Weber]

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

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

 

[Marek Janukowicz]

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

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
No matter which framework you choose, the solution will always be
complicated and ugly. And yes, you can do this in cgikit

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

 

[Florian Weber]

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 .


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

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
No matter which framework you choose, the solution will always be
complicated and ugly. And yes, you can do this in cgikit

not really.

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

how would you do this in xml?

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

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

 

[David Heinemeier Hansson]

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

 

[David Heinemeier Hansson]

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