Stephen Compall <[email protected]> writes: > Poll for readers: do *you* understand the difference between children > and subwidgets as explained in > http://groups.google.com/group/weblocks/msg/dea98b024b164c40 ? > > Jan Rychter <[email protected]> writes: >> As to navigation-rewrite branch (not sure if that is what you meant), >> this is still a work in progress. > > Yes, weblocks-nav4 on Bitbucket is just cherries (with aforementioned > fixes) of your navigation-rewrite branch. > >> Today I managed to rip out container and composite altogether, along >> with all their supporting machinery. Turns out they were just artificial >> constructs, complicating things. The only cost is an extra slot in >> widget and a change in the rendering protocol (I introduced an extra >> render-widget-children GF). > > There is also the danger that it will be even harder to explain the > difference between the two notions of children/subwidgets (the latter > being the superset) then it already is.
True. I've been thinking about what you wrote and I figured I would try a straightforward approach and see where it takes me. I am wary of overdesigning things -- one can design something which is very flexible, but so difficult to use that few will actually understand it. In my current work tree, the only thing I care about are renderable children, loosely defined as "renderable subwidgets worth descending into or that might participate in flows". If a widget has subwidgets that are not worth descending into (say, a pagination widget) and that won't be replaced by flows, it doesn't even have to worry about having it in its children list, even though they might be rendered (by explicitly calling render-widget on it). Our widget tree is incomplete -- and I think that's just fine. When you use inheritance you do run into a problem if two widgets wish to set widget-children. Well, try not to do it then. My pageable-list mixin usurps widget-children -- you can still have subwidgets in whatever you derive from it, but you have to be careful. I am not yet sure how often that will be a real issue in practice. I realize that your solution is more general, but I want to see how far I can go with a simpler approach. Perhaps the issue doesn't arise that often. And even if that fails, I think I would rather avoid generators in CL. I think it will scare people off big time. As for naming, how about children and renderable children? We really have two sets: a set of all widgets (with various interconnections, not necessarily organized into a full tree), and a subset of widgets reachable during rendering that gets generated during what I call a tree shakedown. The latter ones (renderable children) are what widget-children is all about. --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 -~----------~----~----~----~------~----~------~--~---
