New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Implementing Seaside concepts in Rails on Rails?
Posted by Alexis Midon on Apr 03, 2007
Why is Ruby on Rails one of the most popular web frameworks? Does Ruby on Rails introduce many new and revolutionary concepts? Or does it simply offer better implementations of old, common and well-known design practices? That is the first question asked by Giles Bowkett. He illustrates his discussion by comparing the View/Controller patterns in Rails to Seaside's (Seaside is a full-stack web framework built in SmallTalk) components and rendering methods. Would it be worth replacing the Rails views/controllers with an approach more similar to Seaside?
Giles highlights the pros (e.g centralized management) and cons (e.g meaningless URLs) of such an architecture:
couldn't you just emulate Seaside's componentized nature by replacing Rails controllers and views with Builder templates containing objects with built-in render methods which call other Builder templates? And the thing was, it'd work, in fact you'd basically get everything but continuations, but the question was whether it'd be worth it if you didn't get Seaside's session management, and whether the session stuff would or wouldn't be a nightmare in any language but Smalltalk. The idea was that Rails' template system is a big fat smelly onion. We ended up with a design that would probably work much better than Rails, in fact, for Seaside-style development, and still have all the advantages of Ruby over Squeak -- easier DB/Unix integration, more developers, etc.
In the numerous comments, Assaf Arkin kindly responds by indicating how to implement a kind of template-less solution using a capture method in Rails, while Ramon Leon and Giles Bowkett go a step further and envision a best of breed solution implementing Seaside on top of Ruby on Rails.
Despite his innovative ideas, Giles Bowkett is a real Rails aficionado. The ease of development is the best Rails asset but could it turn into a weakness? That's the second question Giles Bowkett asked, fearing the Bram's Law: The easier a piece of software is to write, the worse it's implemented in practice:
...this has always been my fear for Rails; that in five to ten years, the worst jobs you could get will be Rails jobs where you're maintaining stuff built by non-programmers who figured Rails made programming so easy that they didn't really need to understand what they were doing.
RelatedVendorContent
Agility at scale, become as agile as you can be
non programmers
by
Michael Neale
Posted
More on this
by
Michael Pence
Posted
-
Yes, I am sure people laugh at that "fear" - but it has happened before anytime, with easy to use software. Although I am thinking of office automation type stuff, like Excel, MS Access etc (they are the big ones). They were never that popular with programmers, which is one of the differences with rails. If it sticks to its current niche, I don't see any similar danger.
But certainly, the world is powered by apps build on MS Access, Excel etc that were built by non programmers - good or bad, thats just the way it is ! -
I spoke with Seaside creator Avi Bryant about these concepts here: blog.caboo.se/articles/2007/4/8/heresy-and-turt...
2 comments
Watch Thread Reply