Totally agree with you on this.

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

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.

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. :-)

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>
end

... with this one written in Smalltalk:

TodoList>>pendingItems
^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"])
begin
item.destroy
redirect_to(:action => "list"<Wink>
rescue ActiveRecord::ActiveRecordError
render_text "Couldn't destroy item"
end
end

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.

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 ]

...

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 )?

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

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

(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.

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.

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.

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!

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.