"Leslie P. Polzer" <[email protected]> writes: >> Three I can think of -- 1) the make-widget-place-writer problem >> described above, > > I don't really consider this to be a problem. The protocol is > in place and we'd just need to supply a small adapter. > >> 2) the need to supply an *additional* enumeration function >> (which means lots of fun with method combinations to make it >> work), > > What needs to be enumerated, and how?
Someone has to enumerate *all* children of a given widget, in order to walk the tree during the update phase. >> and 3) if you want to control rendering in your specialized >> subclasses, they still need to "know" about these slots and reference >> them directly, which I'd say is just as clumsy as the solution I >> implemented. > > Yes, there's not really a difference. Children classes often > need information about their superclasses and that can't be avoided. Yes, that was exactly my point -- you need a class-specific interface to access them anyway, so it doesn't really make any difference whether you do (map #'render-widget (get-my-superclass-fancy-widgets obj)) or (map #'render-widget (get-children-of-type obj :my-superclass)) >> Of course there is also a small (4) -- get/set-children-of-type always >> operates on lists, promoting widgets to lists if necessary, which means >> you always use map on what get-children-by-type returns. >> >> But, I think the only way to really know is to try -- I did, rewrote the >> code a couple of times and ended up with a solution that is a >> compromise. Like I said, I'm not that enthusiastic about it, but I think >> it isn't such a bad compromise. If someone comes up with a better >> working solution, I'd be more than happy to migrate. > > What I'm trying to figure out right now is what should be at > the core. Custom accessors can be provided above children-of-type > and children-of-type can be implemented atop of slots. > > The latter solution seems more natural and effective to me, > but I'm still very open to be convinced of the converse. Same here :-) > It would be good if Stephen and Slava participated again in this > discussion. > > By the way it's nice to see that we apparently have an agreement > about the other 80% of navigation-rewrite. :) I think we agree that at the very least it is slightly better than what we had before, but I wouldn't consider it "done" -- there is certainly lots of room for improvement. As an example, I'll toss a thought -- I've been toying with the idea of a Clojure web framework. Trying to avoid mutable state, I implemented a widget tree where each widget *may* have a :path attribute. If that attribute is set, it is matched to uri-tokens during rendering. What you get is pretty nice -- a widget tree that renders differently depending on uri-tokens without *any* selectors. Plus there is just one widget tree, you don't have to choose what will be rendered -- the filtering does that on its own. It is a kind of path-to-tree matching thing. The additional bonus is that you can have different parts of the tree react to the same tokens. What makes me happy is that the entire code for walking the tree, matching uri-tokens, selecting and rendering fits on a single screen. I don't think this is necessarily a good match for weblocks, but it's an example of an idea going further than the current navigation-rewrite. --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 -~----------~----~----~----~------~----~------~--~---
