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