Simple diagram: http://viridian-project.de/~sky/nav-design1.png
I think the problem we're trying to solve is grouping widgets together with an arbitrary granularity. Using CLOS slots this works by keeping single widgets or groups of widgets in slots of their parents. The old composite had only one interface to children that was very inflexible; it did not allow grouping the children. The children-of-type solution is a low-level interface that handles both enumeration for the tree walker and children grouping at once. It is basically a simple extension of the composite that allows a child to belong to a group. It suffers from composite's problem in that it lumps together all children. Part of this disadvantage is alleviated by the ability to label one or more widgets, but there's still a huge impedancy mismatch when the user wishes to store the children in separate slots. Advantages of this interface: * simple and uniform * make-widget-place-writer practically for free In my opinion the disadvantage is a heavy one. It forces the programmer to either use an inappropriate tool (e.g. using plain CHILDREN with groups instead of resorting to single named slots) or to code some appropriate mechanism himself. We've already had that with COMPOSITE and MAKE-WIDGET-PLACE-WRITER. The APPEND method has been mentioned as a good mechanism to gather children from all inheritance tiers. This approach also has some problems. First, plainly appending children removes the useful grouping information and we're back at a slightly glorified composite. Not good, but this one can be easily solved: just return an alist that carries the group information in the CAR. This allows only one group per child but can be easily extended to a more elaborate list structure that allows a child to belong to more groups at once. Second -- more grave -- MAKE-WIDGET-PLACE-WRITER doesn't come along easily. We do however have a metaclass for widgets that would allow us to largely generalize this by having a custom slot definition keyword that marks the slot as one to be searched by the children extractor (i.e. the appending method hierarchy). This is especially neat because it allows us to specify the groupings in a natural way -- the slot name also serves as group name, and its contents are the children themselves. It has also been argued that the participation of a whole method hierarchy makes debugging more complex. This is true when compared with children-of-type, but I do think we could offer an in-page interface that would allow us to display what methods have participated in a final children arrangement and which one is responsible for a particular child. See the ticket on halo support which would cover this. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
