Cees de Groot
Tue, 19 Mar 2002 21:27:44 +0100
> 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
> 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,
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
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 <email@example.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B