> 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 don't see why mixins couldn't take the place of 'rendered in different ways' ... I cannot comment on the 'custom metaclass' sentence. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
