Ok, after briefly looking at the code I think I see what you're doing. It's not all that different from the existing system (I was under the impression that your navigation system completely ignores what's currently in place), and the changes that you've made look very nice to me.
Now, some questions. 1. I don't understand set-children-of-type. Your rationale is a widget sharing multiple parents, so you accept the type keyword. First, multiple widget inheritance has moot semantics, I'm not sure when one would reuse a widget and set it with different children in each case. Second, what if both parents of a widget are :selectors? I'm not completely sure what is the alternative, but the scheme in place right now seems pretty difficult to understand for newcomers (which is me :]). Why not (setf widget-children) again? If the parents set children of one of their child widgets, shouldn't it be their responsibility to reset this list every time the tree is walked? Why store this information in the child widget? 2. Currently render-widget-children is called from render-widget. This means that in order for me to have control over how the children are rendered, I have to override render-widget, which means I'll have to do more work than I want to. For example, how would you implement table-composite with this scheme (http://bitbucket.org/coffeemug/weblocks-slava/src/tip/src/widgets/table-composite.lisp)? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
