[Seaside] OmniBase for Squeak
Andrew Catton
andrew-seaside at beta4.com
Thu Jan 27 20:05:59 CET 2005
Cees de Groot wrote:
<snipped and reordered>
>
>
> For The InternetOne (not seaside, but something that looks similar in
> the meantime ;)) we moved most of this stuff away in abstraction
> layers. In fact, we have an abstraction layer that does a lot of work
> based on metadata declarations (object A has attributes X, Y, Z;
> attribute X is of type Foo; etcetera). Most of the database I/O has
> become relatively transparent in that framework and it sports full
> timetravel as well (transparently, mostly). But that of course is a
> thick layer to paste onto something relatively elegant as OmniBase
> and Seaside below. Did I say that you can't have your cake and eat it
> too?
>
We do in fact use a declarative metamodel similar to this, with OmniBase
and Seaside, to handle most of the DB-related annoyances, though some
still get through.
>
> I experimented with mapping the db transactions onto business
> transactions (instead of onto web transactions), but not inside
> Seaside. I think it should be possible to do that and have something
> relatively clean, but of course you get the other issue of long-lived
> locks hanging around (client starts something and then goes away for
> coffee); MVCC makes this usually not a problem, with the exception
> that if A locks an object for writing and goes out for lunch, B can
> still read the previous copy but cannot write it. You can't have your
> cake and eat it too, it seems.
Another issue is back-button support. With Seaside going to great
lengths to allow friendly back-button behavior, we figured it would be a
shame to cancel this out by using non-reentrant DB transactions for our
business transactions. To this end we built another 'transaction' level
for, say, a wizard that edits an object. These 'transactions' create a
deep copy of an object to be edited, with a deep mapping back to the
original object, allowing changes made to the copy to be 'committed' to
the original, persistent object. This allows users of the application
to edit an object, save the changes, then back-button back into the
(possibly multi-page) editor, tweak things and save again. Possibly a
small win, but those sorts of gestures can certainly add up when it
comes to overall user experience.
Andrew
More information about the Seaside
mailing list