> 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