[Seaside] Rolling with Ruby on Rails vs. Seaside

Pablo Iaria iariap at tutopia.com
Fri Jan 28 21:30:42 CET 2005

Hi Benjamin,

If you only need those basic features of an O-R mapper I think you should
see Tantalus (written by Colin Putney).

I've tested with oracle databases using ODBCSqueak and it worked just fine. 
You can use blocks to perform queries. The "missing feature" is that you can
not join tables to perform queries:

You can do:

Clients select:[:each | each name like: 'someone'].

But you can not do:

Clients select:[:each | each address street like: 'somewhere'].

And once you get a client Object you can ask for address as usual.

Hope this helps,

> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-
> bounces at lists.squeakfoundation.org] On Behalf Of Benjamin Pollack
> Sent: Viernes, 28 de Enero de 2005 04:05 p.m.
> To: avi at beta4.com; The Squeak Enterprise Aubergines Server - general
> discussion.
> Subject: Re: [Seaside] Rolling with Ruby on Rails vs. Seaside
> On Fri, 28 Jan 2005 13:06:14 +0100, Avi Bryant <avi.bryant at gmail.com>
> wrote:
> > On Thu, 27 Jan 2005 11:29:28 -0500, Benjamin Pollack
> > <benjamin.pollack at gmail.com> wrote:
> >
> > > 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.
> >
> > The other option to point out here is ROE, which is not an O/R mapper
> > at all, but rather a way to make it more natural to interact with
> > relational data on its own terms from within Smalltalk.  But that's a
> > very different feel from using ActiveRecord.
> >
> I personally actually like ROE better than an ORM, but it, too, was
> limited to PostgreSQL the last time I checked. As Todd pointed out,
> that's a Squeak issue, not a Seaside issue, but the only way of
> getting more choices is to drop money on VisualWorks--a move that
> until very recently put you on murky legal territory on Seaside
> licensing and that still costs a lot compared to Ruby/JSP. I really
> think the lack of interoperability here is a problem. I'm lucky enough
> to still be an undergrad, so when I want "weird" software installed on
> a server, I can usually get it quite easily. But at internships that I
> and friends of mine have done, your application must interface with
> the existing infrastructure. That means it has to play nice with the
> existing databases and the existing IIS/Apache setup. My impression is
> that that's typical, not the exception, and no matter how good
> ROE/GLORP/etc. is, if they can't interface with the existing
> infrastructure, I don't think they'll make major inroads to the
> corporate environment. ActiveRecord, in contrast, interfaces with a
> wide variety of databases already, which makes it much easier to use
> as a drop-in replacement.
> > Having sunk enough time into to O/R trap, I'm in no hurry to do this
> > myself, but: it sounds like you think having an ActiveRecord
> > equivalent for Squeak would be a Good Thing, so how hard would it be
> > to port?  Could it maybe even just be a simple wrapper around GLORP
> > that makes more choices for you, presenting a more ActiveRecord-like
> > API?
> >
> Again, I'm not arguing that O/R mappers are a good idea in general;
> just that they can be optimal for some simple things. Cloning the
> basics of ActiveRecord (minus caching and relationships) would take
> all of ten minutes. Basically you'd have this:
> ActiveRecord>>doesNotUnderstand: message
>         ^ (sqlConnection execute: 'select ', message asString
> asLowercase, ' from ', self class name asLowercase, ' where id = ',
> self databaseId, ';') rows first at: 1.
> although error checking would always be a good thing. :) Caching could
> also be added fairly easily by simply keeping a lazily initialized
> dictionary. When I asked on this list about a month ago what design I
> should have used for my last project when I had to use custom SQL,
> someone even recommended that approach. The main value of ActiveRecord
> is that the constraints you give your model are enforced intelligently
> in both the model and the view/controller.
> >
> > Having written that out, it sounds almost exactly like what Mewa does
> > already - so what are the key differences?
> I haven't used Mewa in anything serious, so I apologize if this is
> incorrect, but my impression was that Mewa just tells the controller
> and view how to validate its data. The model still requires its own
> validation routines. I end up having to code everything twice if I
> honestly believe in an M/VC architecture. If I'm using ActiveRecord
> and Rails, I specify it once. The easiest way to solve this would
> probably be to to provide an object proxy that used Mewa to enforce
> the domain. And again, if I'm out of date on that, I apologize, but
> looking over the documentation it looks as if that is how it works.
> >  Is it just that the
> > metadata is derived from looking at the database rather than specified
> > in code?
> That's certainly a feature of it, and ties into what I said above
> about validation. Column typing information in general is picked up.
> This is very difficult for an OODBMS with lazily initialized classes
> and dynamic typing, such as the design I'm using right now on a GOODS
> app.
> > I think it's an instance of the
> > "provide good defaults and let them be overridden" rule, which I
> > definitely subscribe to, and it seems like there's a whole layer of
> > defaults here that people want that Seaside isn't providing; I'm
> > curious to find out just how "default" they could or should be.
> Rails is absolutely about defaults. The other thing it's about, that
> matters to JSP I've shown Rails to, is that it rigorously enforces a
> very specific design pattern, then leverages that regularity for all
> it's worth. Seaside in general doesn't need these, since it doesn't
> use an HTML templating system and everything in Smalltalk is much more
> transparent.
> I do agree with Michael that Rails is not novel, and after his posts,
> I'm going to have to take another look at Wee. But my original
> point--that for simple and relatively trivial CRUD apps, Rails is
> adequate and potentially faster--I still think is valid. I don't think
> it's coincidence that the Rails demo applications are task lists and
> address books, whereas Seaside's demo application is a full-fledged
> web store. Rails does well when the domain is limited and simple.
> Seaside does well when the domain is extendable and complex. I'm okay
> with that split.
> --Benjamin
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside


Conoce Tutopia, Internet de máxima velocidad, http://www.tutopia.com

More information about the Seaside mailing list