[Seaside] Rolling with Ruby on Rails vs. Seaside
benjamin.pollack at gmail.com
Fri Jan 28 20:05:27 CET 2005
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
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:
^ (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
> 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
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.
More information about the Seaside