[Seaside] Prevayler

Cees de Groot cg@cdegroot.com
Tue, 19 Mar 2002 21:27:44 +0100


avi@beta4.com said:
> There seem to be two obvious
> ways of handling this - either the stub becomeForwards itself into the
> object, or the stub sticks around and just forwards all method sends
> to the real object. 

A third, non-obvious, way is that you rewrite the class and adapt the browser 
to hide this from the user. A fourth way is that you simply compare versions 
of the object to determine whether anything has been changed. A fifth way 
would entail method wrappers (that's a very promising way - clean, available 
now, reasonably easy to work with).

The manual method works fine with stubs that go away, indeed. If you want 
automatic detection of changes, pull your objects to a higher level class (see 
further below).

> However, in any real world situation where you're interacting with
> external systems like an RDBMS, this would be trouble... it only takes
> one html element more or less to completely change the meaning of a
> Seaside url.

I can easily dream up 'real world' situations where you don't need any 
external systems. My website, for example, is quite self-contained and the 
database functionality would just be for content management storage - a 
'abuse-the-object-memory-for-persistence' scheme would work quite nice here.

> You've said something about this a few times, and I'm still not
> entirely sure what you mean.  I'll look at Connectiva, but do you have
> time to give a brief rundown of what you're thinking? 

Basically, Smalltalk lets you describe two features of classes: attributes 
(with just a name) and methods. That's a bit short of what Real Life Business 
Objects[tm] need: you want to attach type information to attributes (string, 
number, money, maximum length, range, validation rules like regexps or code 
blocks); if attributes are not values but reference to other objects, you want 
to describe the relation (cardinality, constraints, 
containment/aggregation/association), etcetera.

In Smalltalk, this is relatively easy to implement. The object itself is empty 
(holds just an object id plus its methods), and refers to a type class, which 
holds a collection of attribute classes describing the metadata; the object's 
attributes are in a collection of data values, which can be values or 
(annotated) references to other objects. Each data value refers to its 
attribute. With DNU handling in the object's superclass you can intercept 
attribute accessors and do checking and transaction signaling at the same time 
(well, probably appropriately refactored in different methods :-)). So "self 
phone: '+31.abcd'" will go to DNU, will then be redirected to the validation 
method for the 'phone' attribute in the object's metadata (class) description, 
if that one returns "all green" the value will be stored in the data value for 
'phone' in the object and the current transaction will be signaled that the 
object (or maybe just the data value) has been changed. When you create an 
HTML form, you simply fetch an attribute and ask for its label, then ask for 
its default HTML input element representation, then feed its validation method 
through a Smalltalk->Javascript generator.

OBTW: It's 'Objectiva', not 'Connectiva'. Some bad-wired neurons messed things 
up, my apologies for that.
 
Canonical paper is http://www.joeyoder.com/Research/metadata/objectiva.pdf. 
The PDF doesn't look like it contains the finished paper, but there's enough 
info in there. Page 23 has the core model, page 25 has an instance diagram - 
just looking at these two will give you the idea.

The biggest issue with these things is that you need to write browser 
enhancements to make it feel like 'natural Smalltalk'. For example, we have 
implemented the basic pattern on Page 23 where the attribute metadata is in a 
class-side method (Foo class>>attributes ^super attributes, #(.....)) but you 
need to remember to invoke some attribute-reading method whenever you change 
it, etcetera. Ideally, the browser would be able to toggle between "class 
methods", "instance methods", "comments", "class attributes", "instance 
attributes", where the latter two would present you with an interface to 
define/edit attributes. One step down the road, and apparently the reason 
these 'dynamic object models' are so hot, is that you let the user define 
everything (yeah, sure...).





-- 
Cees de Groot               http://www.cdegroot.com     <cg@cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B