Ah correction, the menu will probably not work for me, I forgot I played around with the definition so strike that one out.
On Tue, Jan 12, 2010 at 10:42 AM, Henrik Sarvell <hsarv...@gmail.com> wrote: > This will not work, as '<menu>' expects a list structure as argument. So >> the global '*ClassTreeMenu' will not be evaluated. >> > > Well it does work for me. The menu appears and all just like I want it. > > > As 'crud' is a function, it is easier if you pass the class simply as a >> direct argument >> > > I'll try it out, maybe it will enable me to get the class in crud too? If > not I'll just make a new file with this stuff just like in the demo app. > > > 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). >> > > This is just meant to be a tool in very much the same way as PhpMyAdmin is > a tool for me when using the LAMP stack. I would never simply create the > database schema, install PhpMyAdmin and present it to the customer and say > "Her you are, your finished application" (although it would be fun to see > the expression). > > That does not stop PhpMyAdmin from being perhaps the most important tool > during development, in the same way PicoAdmin will be when I'm done with it. > > Sure, when developing "traditional" applications that will use the > traditional GUI framework PicoAdmin will not be much of a use as it would be > tangental to the finished application. > > However when creating applications that will use a completely different > approach this tool could be very handy for inspecting the database. > > An alternative that might suit all kinds of application developers could > perhaps be a scaffolding script that generates the equivalent of choCuSu and > saves it. This basic stupid thing could then be edited by hand if the goal > is a traditional GUI or simply used as is if it is not. > > In fact the more I think about it the more I like the idea of a scaffolding > script, I think I'll go that way instead. > > > > On Tue, Jan 12, 2010 at 10:05 AM, Alexander Burger > <a...@software-lab.de>wrote: > >> 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 >> > >
