Hi Konrad,

> I've being trying to work out how the Family.l application hooks
> together its database and gui objects together and simply haiing no
> luck.
> 
> as far as I unsetad the current Person object is being stored in the
> global variable *ID by the (default *ID (val *DB)) call.

*ID is used only temporarily, to communicate the object across HTTP
calls as URL parameter.

The "real" place of the object is normally in the 'obj' property of the
form. The crucial call here is

   (<id> ...)

'<id>' takes care of storing the object in *ID into the 'obj' property
of the current form, enable or disable the form according to certain
rules, and lock the object if necessary.


> but then none of the gui calls seem to reference this object at all.
> So how is one hooked up to the other.

There the crucial item is the +E/R prefix class (as you noticed). It
takes care of "connecting" the displayed value in the GUI component to
the internal DB object's attribute.


> Also what are the initilisation arguments to the +E/R prefix class

They take the form of a cons pair, with the attribute (relation) in the
CAR, and an executable expression giving the object in the CDR.

Whenever +E/R needs to read a value from the object into the GUI, or
write changes from the GUI to the object, it evaluates the 'exe' in the
CDR to obtain the DB object.

> supposed to mean '(nm : home obj) . The first one appears to be
> relation name but what does the rest of the lsit do.  I've tried

So 'nm' is the relation (e.g. the person's name), and '(: home obj)' the
object expression. As the object is stored in the 'obj' property of the
current form, and each GUI component knows the form it resides in from
its 'home' property, '(: home obj)' means: Get my (the GUI component's)
home form, and from that the object.

> readin the code and the libraries it imports and re reading the
> Applicaton development document several times but it just seems to
> skip over this point. We have information on DB programming and

The documentation is not (yet) complete here. It's really a lot of
stuff, and explaining it all would probably be longer than the
implementation itself. I hope this will improve in the future.

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to