Hi Sundar,
> As you can see below there are two classes, one for customer basic
> info and another to record the order placed.
>
> *| class +Info | class +PizzaOrder
> >|*
>
> *|--+-
> > |*
>
> *| (class +Info +Entity) | (class +Order +Entity)
> > |*
>
> *| (rel name (+Ref +Need +String)) | (rel ord (+Key +Number))
> > |*
>
> *| (rel number (+Number))| (rel dat (+Date))
> > |*
>
> *| | (rel typ
> > (+String)) |*
>
> *| | (rel sze
> > (+String))|*
>
> *| | (rel cus (+Ref
> > +Link) name (+Info)) |*
>
> *| |
> >|*
>
> ...
(quote
@Nm (val> (: home search))
(select (@search)
((cus +PizzaOrder) (name +Info))
I think '+PizzaOrder' must be '+Order', according to the model. But as it
is not searched for, this clause should be omitted anyway.
The generator clauses need to know what to search for, so we must pass '@Nm'
(quote
@Nm (val> (: home search))
(select (@search)
((name +Info @Nm))
Concerning the filter clause
(tolr @Nm @search cus name)
'tolr' is not suitable here. As the 'name' relation is a '+Ref', we need bo use
'head' (or change the 'name' relation from (+Ref +String) to (+Sn +Idx +String)
for personal names). For a listing of meaningful combinations, you could check
https://software-lab.de/doc/search
> questions:
> 1. this 'put' and 'get' is what I find difficult to grasp.
The put function transforms the internal representation of the chart (in case of
'select' a list of objects) into a 2-dimensional representation for the table in
the GUI (always a list of lists). It depends on what is shown in the GUI.
The get function does the reverse. For a pure query chart, which does not allow
editing, it is omitted.
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
