Chris Hallwright wrote: > > I'm thinking of a different way to arrange the example demos to help > new-comers struggling with back ends. (No change to the simple-blog > though).
That's a good idea. The demo needs some fresh air in more than one way. > weblocks-demo does use an object model, exploiting inheritance > (employee - person) and composition (address - person) but with only > two simple storage options. One is a memory store used in the online > demo, and the other is a simple persistent XML store, which requires a > bit of hacking to get working. It also doesn't show another important thing that is pretty simple to do, the ability to customize a grid's query (e.g. a gridedit that shows part-time employees only). > 1. weblocks-memory-demo. The current on-line demo with data in > hunchentoot sessions. > > 2. weblocks-object-demo. The store could contain variants for > XML simple persistence via cl-prevalence > clsql with postgresql (and postgresql-sockets) > elephant with postgresql > elephant with berkely db > ... and we should be able to add allegro cache at some stage Why can't those two go into one? Or do you propose some entirely other thing for (2) than the simple company/employee model? > 3. weblocks-relational-demo. The store could initially contain > variants for > clsql with mysql > clsql with postgresql (and postgresql-sockets) What sort of special (CL)SQL features do you wish to employ here? > I'd do the initial work - I need the practice. IMO that's a very good way to practice. Leslie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
