WebObjects Could Learn From Rails

Rails is getting a lot of attention. The interesting thing is that it's not just hobbyists that are picking up on it. Even big companies seem to be figuring out that immense, five- and six-digit application servers don't necessarily make them any more productive than community-authored frameworks. In some cases, the free stuff is acutally more practical.

Rails is interesting because it's a rapid development environment that abstracts the developer from many of the monotonous, low-level details of web apps. It's probably fair to say it's in the same spirit as Core Data, but aimed at the web. In fact, there seems to be quite a bit of overlap between the Ruby and Mac OS X communities.

The irony here is that Apple already has a rapid development web application framework, and has for quite some time. It's called WebObjects, and it's the basis for many of the ideas in Core Data.

The problem, I think, is that Apple has been positioning it almost exclusively as an enterprise application platform. It can do that, but it shouldn't be limited to the elite. It's true that WebObjects no longer costs as much as a car, but there's much more to positioning than the price tag.

I assume Apple's object-relational folks were rather busy with getting Core Data out the door, but I think the time is right to take the core of WebObjects, and recast it as a new, more general-purpose application framework under a new name.

This package must be be based on (or at least support) Objective-C. It should take the new engine and modeling tools introduced with Core Data/Xcode 2.0, and layer on the parts that are important to web applications. At this point, I think Ajax-style classes would be an absolute necessity.

Rails is a great framework, but there are a certain things about both Ruby and Rails that that I've found clash with the elegance and consistency that Cocoa developers are used to. I don't think Apple should underestimate the significance of web app development tools.

See MacZealots' Installing Rails on Tiger article if you want to play around with Rails.
Design Element
WebObjects Could Learn From Rails
Posted May 30, 2005 — 12 comments below


Glenn — May 31, 05 183

Totally agree with you on this.

Hopefully this can be brought up at the WWDC next week...

Dale — May 31, 05 184

In contrast with Rails, the problem I see with WebObjects is its overall cost and complexity to deploy for small-medium business. That is, most businesses.

It doesn't bring a lot extra to the table for quickly building basic web apps for small to medium enterprise when compared to Rails. But in comparison it costs a prohibitive amount to deploy.

You could say that Rails is Xserve, and that WebObjects is Windows on a DELL server, at least from the perspective of Apple's core business users.

WebObjects appears to have missed the Enterprise boat. The price reduction back in 2000 was too little, too late. Apple need to retool it and aim at small/medium business. This is what Rails has done. It's not the fastest performing web app platform, doesn't have a zillion extra features available via third party Java packages. But it's the Mac of web apps - simple to use, extremely productive for developers, and does most tasks very well.

As an aside, I'd like to see Rails and all the Ruby Gems included in Mac OS X.

Justin Williams — May 31, 05 185

Rails is a great framework, but there are a certain things about both Ruby and Rails that that I've found clash with the elegance and consistency that Cocoa developers are used to.

Let me guess, this is the next post? I certainly hope so. :-)

hitoro — May 31, 05 186

IMHO Rails is overrated. While it sounds great to hide the data model and to only bother about the controller and the presentation layer, I think it tries to solve the wrong side of the problem. The difficulty is not in defining and using the data model but to manage the flow between controllers and views. It still requires to think how to go from one view to another and to break the controller into pieces.

I have tried a few weeks ago to adapt the Rails' Todo-list tutorial to Seaside and Mewa; while I have written a bit more code on the data model side, mainly accessors and convinient methods, the controller and the views were almost free of code.

The problem I have with the Rails' tutorial is that the Todo model is used to represent both a single item and an array of items. The other problems are that you still have to use SQL statements and HTML templates to get the things done.

What's the deal? Compare this method for retrieving pending items:

def self.find_not_done
find_all("done = 0", "description"<Wink>

... with this one written in Smalltalk:

^self items reject: [ :each | each done ]

TodoList is a subclass of a Collection and contains instances of TodoItem. The object tree is nicely defined and self contained, and the method is, well, nice.

Deleting a Todo item with Rails is even trickier:

def destroy
item = Todo.find(@params["id"])
redirect_to(:action => "list"<Wink>
rescue ActiveRecord::ActiveRecordError
render_text "Couldn't destroy item"

In that "destroy" method, you have to retrieve the id and do a redirection to make the things tick. In Seaside, you don't to worry about such details:

TodoListComponent>>renderItems: items on: html
html form: [ batcher batch do: [ :item | html span: item description. html anchorWithAction: [self delete: item] text: 'Delete'. ].

In short, this method visits the items and renders their descriptions on a stream with a link to delete the corresponding item in a row.

The most interresting line is the call to the anchorWithAction:text: method. It binds the block [self delete: item] to a link with the text 'Delete'. When the visitor will click on that link, Seaside will execute the block and delete the item corresponding to that link.

Yes, that's inline binding of code. No need to worry about passing ids, inserting values in HTML templates or using SQL statements, you work with first class objects.

Sorry for the long post, but I have that thing in mind since a long time ago.

hitoro — May 31, 05 187

Oh, I forgot to tell you one last thing.

The code behind the delete: method sent to self is:

TodoListComponent>>delete: aTodoItem
(self confirm: 'Do you really want to delete ', aTodoItem description, '?') ifTrue: [ model removeItem: aTodoItem ]


Jean — Jun 01, 05 188

Is the use of SQLlite for Ruby obligatory? Or could you (as an alternative) also use an object-based db engine (such as www.db4o.com )?

Scott Stevenson — Jun 01, 05 189 Scotty the Leopard

This is the first I've heard of db4objects, but you're certainly not limited to SQLite with Ruby.

rff — Jun 01, 05 190

hitoro, I guess you could reqrite the find_not_done in ruby like
def self.find_not_done
descriptions.reject {|x| x.done? }

(rubists love blocks as much as Smalltalkers do <Wink> but this would move the selecting from the database ti ruby code withouth adding much.
I agree on the part about linear programming with modal frameworks.

Scott Stevenson — Jun 01, 05 192 Scotty the Leopard

Ironically, these examples highlight what I mean about Ruby clashing with the elegance and consistency of Cocoa. A lot of Ruby syntax is short in terms of characters, but not all that great to read.

Plus, there's just so much syntax. One of the really nice things about Objective-C is that the language is so small, that the landscape of ObjC code is fairly flat. There aren't huge differences from one codebase to the next in terms of syntax.

I don't mean to bash Ruby too hard here. It seems nice and I need to spend more time with it, but I've seen a few things already that were a bit shocking in terms of readability.

Daniel Cremer — Jun 02, 05 194

Hitoro you might be interested in another ruby framework called IOWA which is a bit more elegant in the way you describe. It was originally started by Avi Bryant who maintains Seaside now.
In it you indeed have hyperlinks that automatically action the code on an object the represents the page. It's all done automatically for you and is very intuitive if you like OO.

helge — Feb 04, 06 740

I do not understand the hype around Ruby. I mean yeah it would be great to do all coding the smalltalk-way. But this willl not happen.

WebObjects is not only a Framework-Collection, its a Framework-Collection with a track-record in stable and high-performing apps. And its at the same time a track record in regard to a real CASE-Tool-Suite (Computer Aided Design), which consists of WebObjects Builder (GUI), EOModeller (Data), xCode (Business Logic) these three tools are integrated and bring you productivity.

I think if you calculate development costs then deployment costs are only a marginal question compared to the total volume. In the end deployment under Mac OS X Server may be the cheapest you can get (if you think TCO).

I would never switch back to a script-language which mixes SQL-statements right in the code. No this is clearly not what I expect from a technology 21st century style.

WebObjects only needs some refurbishment for things like CSS, AJAX, JavaMAIL integration, RSS-Feeds and perhaps an adaptor for ObjectOriented Databases and they are top in business again.

Problem is, that Apple does not give even one clear statement what they are planning on WebObjects's future. And that is a major barrier for enterprises to jump on it. One clear statement from Apple would be able to solve this!

Scott Stevenson — Feb 07, 06 751 Scotty the Leopard

I do not understand the hype around Ruby

It brings a lot of concepts pioneered by WebObjects down to a much more accessible level, both in terms of cost and deployment.

I would never switch back to a script-language which mixes SQL-statements right in the code.

The idea behind Rails is to not do that. There are cases where you can if you want, but it's not the norm.

One clear statement from Apple would be able to solve this!

That's it in a nutshell.


Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.

Copyright © Scott Stevenson 2004-2015