This post originated from an RSS feed registered with Ruby Buzz
by David Naseby.
Original Post: Rails vs Iowa, Take 2
Feed Title: naseby + ruby + stuff
Feed URL: http://homepages.ihug.com.au/~naseby/rss.xml
Feed Description: Random wanderings through Ruby.
The initial release bumps seem to have evened out in a remarkably short time, and the word from the community remains overwhelmingly positive, so I’ve decided to give Rails another go. I followed the really rather good documentation to get it working in short order. Rails provides an excellent level of help to get things started. I find the initial stages of a project to be the hardest – just getting something to display, with some frameworks, is tremendously hard or annoying. Rails circumvents that stage, with scaffolding methods and helpers and code generators and tutorials and documentation.
My major beef with Rails is still beefy – I am simply turned off by the amount of code mixed in the html. What really gets me is that Rails is so close to allowing the other kind of pure, exemplified by Seaside, pure code to generate the html. Stepping back a bit: I like purity, either pure XHTML with funky processing to dynamically alter it at runtime (Cerise is probably the best example of this in the Ruby world), or pure Ruby that generates html programmatically (the venerable CGI module in Ruby provides about the worst possible example of this… see Borges for a much better version).
Rails already provides a bunch of helper methods that generate html, such as link_to and text_input. The tutorials show how to make more. If I had one wish for Rails, that would win the prize of my devotion, it would be to add a bunch more helpers, with the option of generating pages purely from helpers, without any <% business.
Anyway. It looks like its not too far off allowing a hacked out version of this style anyway. So I’ll progress down that track, for my further Railsy delvings, and get back to you all if it works. I’m still concentrating on Iowa, as it still does what I need, and well, and quickly. Iowa isn’t pure, using the definitions I’ve placed above, but it leans on the side of html inclusions rather than code inclusions, and that somehow annoys me less. Probably scars from years of ASP.
Other than purity, another reason I’m not entirely content in Iowa-land is debugging. Every time I add a component, I feel pretty certain that I’ll screw some binding up, or miss something, and I’ll end up with a stacktrace in WEBrick with the dreaded ‘nil does not respond to…’ error, plus a bunch of useless info for the classes that did the eval-ing of the buggered component. I’ve learned now not to panic about it, but it would be nice if I could get some better info about what I’ve forgotten, and where.
Iowa also uses the uri as a session marker. This has some big advantages – sessions don’t expire, and don’t depend on cookies – but some large disadvantages. Rails has a beautiful uri system of root/model/view/. All REST-y and cuddly. Iowa can never really manage that system without a major revision to session and application management. It would be really nice, though…
Anyway. I’ve done 2 projects in Iowa (well… really 2 versions of the one project), which was the same project I developed to some extent in Borges as well (the project management thing). I will attempt to develop my next hobby project in Rails. Can’t be any fairer than that, can I? I don’t think I’ll do the same project, even though its a good benchmark job – I’d just feel a bit dirty making a project management tool in Rails, considering thats been done before.
Previous Topic
