Re: How do Relations and gui objects hook together.

2012-02-22 Thread Konrad Zielinski
Hi Alex

Thanks for the explanation. Though this really should be mentioned in
the documentation. Its a rather obscure call in Family.l which just
looks like its creating a Heading.  but it turns out to be vital for
the application to work.

I notice that there are a few other methods defined in form.l that are
not actually documented anywhere. The button helpers I can sort of
work.  But the choDlg and panel with their long and rather complicated
argument lists are somewhat harder to puzzle out.

regs

Konrad


On Thu, Feb 16, 2012 at 8:02 PM, Alexander Burger a...@software-lab.de wrote:
 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



-- 
read my mind at: http://the-willows.blogspot.com/
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: How do Relations and gui objects hook together.

2012-02-22 Thread Alexander Burger
Hi Konrad,

 Thanks for the explanation. Though this really should be mentioned in
 the documentation. Its a rather obscure call in Family.l which just

Yes, that's true.

 I notice that there are a few other methods defined in form.l that are
 not actually documented anywhere. The button helpers I can sort of
 work.  But the choDlg and panel with their long and rather complicated
 argument lists are somewhat harder to puzzle out.

In fact, the whole form.l GUI is explained only rudimentarily so far.
It is a huge task. We are planning to start an open source ERP project,
perhaps the situation will improve along that course.

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


Re: How do Relations and gui objects hook together.

2012-02-16 Thread Alexander Burger
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