nunb <[email protected]> writes: >> 1. It should be as compatible as possible with the old one. > > Won't defview syntax change? > >> >> 2. It should be easy to override a single slot of a view. >> >> 3. Inheritance must be working and customizable. We should also try to >> offload inheritance stuff to CLOS to get rid of the ugly machinery >> currently employed. >> >> This all just off the top of my head... > > This from http://www.defmacro.org/ramblings/ui-dsl.html sounds rather > ominous.. (perhaps it means that using the --same-- clos class for > data + views does not work?) > > === > The class definition is so succinct, one may wonder why not use CLOS > classes in the first place without defining a custom language. In > fact, this is the route I took initially, only to find out later that > it doesn't work. The same object is often rendered in different ways, > and people aren't very fond of changing their data model to change the > way a field is rendered. I also couldn't define a custom metaclass so > that specialized rendering information for each slot could be put in > place. Firstly, more often than not model classes already have a > custom metaclass to allow for mapping to a backend store, and secondly > this wouldn't easily accommodate creating multiple different views of > the same object. > ===
I think what was meant here was that adapting your model classes to also serve as views does not work. I fully agree. --J. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
