Vyacheslav Akhmechet <[email protected]> writes: > 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.
I find multiple inheritance to be tremendously useful. As an example for our discussion, let's pick the "commentable" mixin class, which itself is a subclass of pageable-list, a widget that combines a pagination widget with a list of widget items. I can make any other widget "commentable" just by adding commentable to the list of superclasses (well, subject to database model restrictions). This is tremendously useful. > Second, what if both parents of a widget are :selectors? I guess if it hurts, don't do it then :-) I mean, not all combinations will make sense, but I don't think this is a problem. > 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? There is one widget-children slot -- how do you combine the various children that each of your parent widgets has? How do you maintain that list -- remember that on a tree update we need to update the list of children. In the example above, a request to go to the next page of comments might have come in. Now someone has to update a _part_ of widget-children with the new comments. It's impossible to do using (setf widget-children), all you can do is have each widget maintain its own list and then have them compose all the lists together. All I did was provide a uniform interface for these kinds of hacks. The other rationale is that when you subclass other widgets, you might want to control the rendering order. This was important in my application. Since your specialized widget has to "know" about all superclasses anyway, one might argue it can also know about their children types -- so it can override all rendering and control it itself. I realize this is controversial and I myself am not that happy with this solution. However, it's the best I could work out, it is reasonably simple to follow and easy to debug (way easier than method combinations) and works. > 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)? No, the goal was for you to override render-widget-children. I have places where I override it to do nothing at all, because render-widget-body handles all the work explicitly. --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 -~----------~----~----~----~------~----~------~--~---
