Stephen Compall <[email protected]> writes: > Jan Rychter <[email protected]> writes: >> I don't think rendering has much to do with it, though -- we have other >> widgets that do not render (containers?), but serve useful purposes >> within the tree. > > Containers do render; you are required to come up with a render for > them. > > If, and I believe it is sensible to keep this setup, a dispatcher must > be hierarchically positioned above sub-dispatchers, then they cannot be > pure leafs. Since this is the case, each dispatcher must accept at > least one child, and this might as well be the function-selected cache. > > The idea of a dispatcher choosing widgets elsewhere in the tree is > certainly valuable. But this can happen anyway; it is merely a matter > of communication. For example, a dispatcher that you do not wish to > select for different widgets at that point in the tree, but at some > other arbitrary points, can adjust those locations manually, and always > return the same widget to be "selected".
Stephen, I believe our viewpoints are not very far apart. My main point is that I don't think *every* dispatcher should carry the full on-demand content-generation functionality along with caching. I'm still working on the design, and for the moment it seems as if one could nicely separate a dispatcher-mixin (doing uri-token processing and not being a widget), and have an on-demand-content widget or similar that would do what you want. A draft illustration is here: http://screech.rychter.com/files/weblocks-new-nav-design-20081213.pdf That way you would still have a simple way to autogenerate content, the dispatching functionality would be abstracted away from rendering, dispatchers would dispatch and selectors would select. And we wouldn't have to deal with things like selector-on-dispatch, render-dispatcher-content and render-dispatcher-decoration. That approach would also avoid the traps you pointed out: building pseudo-widgets that don't really render and overly complicating the dynamic content generation case. --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 -~----------~----~----~----~------~----~------~--~---
