Hi Henrik,
>
> (de menu (Ttl)
> (action
> (html 0 Ttl *Css NIL
> (<div> '(id . menu)
> (<menu> *ClassTreeMenu))
This will not work, as '<menu>' expects a list structure as argument. So
the global '*ClassTreeMenu' will not be evaluated.
> (setq *ClassTreeMenu
> (make
> (for Cls *ClassTree
> (link (list (sym (car Cls)) (pack "@crud?class=" (car Cls)))))))
> ...
> pressed I want that class name (+Feed for instance) to be available in the
> crud function. This is not succeeding with (get Key 'http) anyway. And the
As 'crud' is a function, it is easier if you pass the class simply as a
direct argument:
(pack "@crud?" (car Cls))
...
(de crud (Cls)
...
> demo app isn't helping because individual files are used whereas here the
> goal is to generate the GUI in a generic fashion which makes separate files
> seem a bit overkill or?
Not sure, but you will probably need at least a set of methods per
class, which return or generate some necessary parameters. You could use
these values to build a 'menu' function dynamically, which internally
calls '<menu>'.
> Another thing that surprised me is the use of lower case in +relation which
> was surprising, is there some special reason or a typo?
Yes. Per convention, abstract classes are written with a lower case
character following the '+'. Other examples are '+index', or '+gui',
'+field', '+numField' or '+obj'.
> Later on when retrieving the +Entity whose relations I want to use works, I
> want to be able to have a generic search form where all the entries are
> simply compared, the functionality I'm after is a (db) that will return a
> list of results, not just one item if there are more matches. I suppose a
> comparable pilog query would be if "same" is used to compare all the fields,
> however generating a working pilog query seems overkill.
>
> I hope I'm not too confusing here, the main goal is to create a basic CRUD
> interface in line with choCuSu in app but all the information to build it
> will have to come from introspection of the +Entities and their relations,
> that plus conventions on what to do in certain cases. The reason for doing
> this is that it could be dropped into any project and instantly provide a
> working (but stupid) CRUD interface.
This idea sounds good, but in my experience the variability of search
options - depending on the purpose of the application - is rather large
and does not only depend on static information, but also on other
requirements of that application. In a certain way, the E/R model and
the corresponding searches are the core of an application. I believe you
would use a lot of flexibility with a static approach. Instead, the
intention was to enable the programmer to formulate solutions for such
requirements in a concise form, instead of generating them
automatically.
'choCuSu' is just one search, used in the GUI. In a larger app, there
are more similar searches, for different aspects. For the 'C' in CRUD
(create), there is usually a 'T' method which does the most basic
initialization, and the rest is handled by arguments to 'new' which also
vary a lot, depending on the situation. Reading (R) is transparent
anyway and doesn't need any special handling, while updates are similar
to "new". Deletion (D) is also mostly automatic, and can be fine-tuned
with local 'lose>' methods in entities and/or relations.
So you see, I'm generelly not a friend of any automatically generated
code. It requires a different (static) way of thinking, and lets you
lose the advantages of picoLisp, which strives for succinct and flexible
dynamic code (as opposed to static definitions).
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
