[Seaside] Rolling with Ruby on Rails vs. Seaside

[Michael Neumann]

Benjamin Pollack wrote:
> On Thu, 27 Jan 2005 15:13:27 +0100, Michael Neumann <mneumann at ntecs.de> wrote:
> 
>>Dmitry Dorofeev wrote:
>>The default forms you mention is AFAIK not comparable to Mewa. All you
>>can do with it is to edit one "flat" row of database table, where you
>>show one form-element per column (which form-element you show depends on
>>the column-type, if it's DATE, then you show a date-selection field, if
>>it's VARCHAR, then you show a single-line edit field, if it's TEXT, then
>>you show a textarea and so on...). AFAIK, it can't handle automatically
>>relationships to other tables.
> 
> 
> Fully automatic, no. You do have to modify the model class to specify
> the relationship in code, but we're talking about one line, and it
> remains vastly simpler than, say, GLORP. For example, if I were to
> trying to make an appointment book, and have a table people and a
> table phones and want people to have zero or more phone numbers, I can
> do this:
> 
> class Person < ActiveRecord::Base
>    has_many :phones
> end

Sorry, what I meant was whether the scaffolder automatically displays 
such relationships. I haven't found any example of it, and looking at 
ActionPacks scaffolding-code, it seems to be not implemented. How would 
  RubyOnRails display such relations? In-Place or as a link "edit phones"?
I'm interested as I'm currently writing such a scaffolder for Wee+Og.

> and the scaffolding will automatically pick that up. This design is
> highly reminiscent of Mewa to me, but actually (at least for simple
> things) cleaner, and it works on both the model and the view layer at
> once, not just one or the other. Rails supports quite a few such
> one-line relationship specifications, including many-to-one,
> one-to-many, many-to-many, conglomerate wrappers, and so on. They're
> detailed quite well in Relational Rails tutorial at
> http://wiki.rubyonrails.com/rails/show/TutorialBasicRelational .

One problem with the relations is, that the person-object must exist 
before you can add phone-numbers to it. In Mewa this is simple, as you 
can easily roll the canges back by using the cached values. Not so if 
you use ActiveRecords (and similar OR mapper). 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). Sorry if this was a 
very confusing description ;-)

Any hints on how to handle this?

>>Seaside is IMHO much better suited for highly dynamic
>>web-applications. Rails has "nice"-URLs, that's the biggest advantage I
>>see on
>>their side (and of course it's a "hype").
>>
> 
> 
> Having used both, I agree that Seaside is much nicer for dynamic
> sites, but I also think that calling Rails hype is dangerous. There
> are some things that it does get right, in my opinion. The best part
> of Rails to me is not Rails vs. Seaside but ActiveRecord vs.
> GLORP/GOODS. GOODS is great if you have full control over the server
> and don't really need to interface with anything. If you are trying to
> write an application to interface with existing relational data,
> though, or if you want your database to be accessible from
> command-line, web, and GUI components, an RDBMS may be your only
> solution. That gives you the choice of either coding the SQL manually
> or using GLORP. GLORP is more powerful than ActiveRecord; I'm not
> challenging that. But it's also much harder to use, getting things
> running can be surprisingly complicated, and for many things,
> ActiveRecord is sufficient. GLORP also supports essentially only one
> database on Squeak (PostgreSQL), whereas ActiveRecord supports all of
> the major ones at this point. For quite a few projects, that's a
> showstopper, and it happens before we even really get to the
> web-framework level.
> 
> The other thing that is appealing about Rails for most of the
> developers I've talked to is the speed of development for simple web
> applications that provide little more than CRUD. If all you want is a
> quick GUI on a database, Rails goes extremely quickly, and the
> scaffolding ends up being mostly sufficient. Seaside goes much more
> slowly for this part of development. A lot of web apps these days are
> just CRUD, and I think that many developers find Rails a lot easier
> for that.

What do you think is the reason? Imagine you could use ActiveRecords 
from Seaside (or Wee), and you can use a Scaffolder like this:

   component = Scaffolder.new(DomainClass)
   html.render(component)

Do you think Rails templating approach makes it so fast to develop?

> I'm really not sure that Seaside and Rails can or should be
> competitors though. Rails buys you next to nothing when your website
> advances beyond CRUD. Although its developers have worked hard to try
> to give you a modular framework, it can't compare to Seaside
> components, and I really missed the modal framework at several points
> when I was working in Rails. Conversely, Seaside cannot, at the
> moment, get a simple CRUD application up in juts a few moments with
> pretty URLs. I'd love it if Seaside could do that, but I also really
> do feel that Seaside and Rails are solving different problems, and
> both solve them pretty well.

CRUD in Wee/Ruby (see example above) is now damn easy. But of course 
without nice URLs. I don't know GLORP, but if it would provide some 
meta-data, it would be very easy to do the same in Seaside.

Regards,

   Michael