From: Bauduin Raphael Date: 2004-07-26T01:21:53+09:00 Subject: Re: rubyonrails and cgikit comparison 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 http://media.nextangle.com/rails/ror2bc.pdf, I saw >> this code: >> >> <% for comment in @post.comments %> >>
  • <%= comment.value%>
    • >> <% 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: > > > > 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 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. 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! :-) 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 > > >