[Seaside] Rolling with Ruby on Rails vs. Seaside

[James Megquier]

Fascinating discussion; I tried to build a project in Seaside earlier 
last year, but have switched to Rails for the time being.  I do plan to 
come back to Seaside (because it rocks) -- but among my friends and 
co-developers, Rails is much easier to comprehend if one is unfamiliar 
with Smalltalk.

[It's also been much easier to convince potential clients, especially 
their in-house techies, that Ruby/Rails/PostgreSQL is okay.]

Hopefully, Rails and Seaside will be able to borrow good ideas from 
each other.  In addition to a lot of "sensible defaults," Rails offers 
you a trade-off: obey these simple conventions, and the framework will 
give you a lot of help.  It may vex the purist in me, but it is 
remarkably effective.  (Come to think of it, that summarizes my feeling 
about Ruby vs. Smalltalk... ;-)

I just wanted to respond to this comment:

> So, if you want to "create" a new Person object, then click on "add 
> phone-number" in the scaffolded "edit" and add some phone-numbers, 
> then go back to the Person object editor and then decide to not click 
> the "Save" button, then that Person object is still in the database 
> (as it was required to save it to the db before you can add a 
> phone-number to it).

As of Rails 0.9.4, (about two weeks ago) you could persist the unsaved 
person into a "session" variable while you called phone-number/edit, 
and then save or cancel the whole thing back on the New Person page.  
I.e. you can now create associations among unsaved objects (and they 
get saved correctly at the end), but since there are no continuations, 
you still have to persist the unsaved object somewhere across pages.

BTW, I don't think it would be too hard to add automatic scaffolding to 
Rails for the non-simple columns (the associations and aggregations 
mentioned earlier); not sure why no one's done it yet. Often the 
scaffolding is temporary anyway, quickly replaced with custom-written 
code.

Cheers,
-James