Stephen Compall <[email protected]> writes: > Jan Rychter <[email protected]> writes: >> Ok, I have the first cut of the new nav design, it works for my >> application so far. Dynamic wiki-style on-demand navigation is untested. >> >> It turns out Stephen was right being suspicious about the dispatcher >> (Stephen, thanks for your comments!). In my design the dispatcher is >> gone, so is selector-mixin. A rough diagram of what things look like is >> here: >> http://screech.rychter.com/files/weblocks-new-nav-design-20081214-2.pdf > > I really like this. Some points: > > * I don't think it should subclass `container'. See how I've stripped > down `container.lisp' in [1]. Container seems to be becoming a > type-tag (as it is for selector), leading webapp authors down the > path of indiscriminately spraying it on their widget trees; this is > part of my motivation for removing CUC/CUDC in favor of widget tree > walking.
Thanks for your comments. As I understand it, the only purpose of the container is to keep a list of children, e.g. maintain tree structure for non-leaf nodes. If you remove it, where do you keep the list of children? Do we make all widgets keep that list? If we make all widgets keep a list of children, I'm all for removing the container. I just wasn't sure whether we want to carry that baggage around. > * I'm not great at naming, but shouldn't the name of `selector' reflect > that it is related to URI parsing? If `selector' communicates this > effectively, ignore this point. I'm a naming nut, I believe naming is very important, especially now that we read code more than we write code. See how I'm going around renaming things like widget-current-navigation-url to widget-uri-path. But in this case, I think the selector name is right. Its role is to provide a selector (switch) in the tree, that selects something among several widgets. It does so based on uri-tokens (for now), but it doesn't have to be the only way. But -- if you get rid of it, you might as well put everything into 'widget'. Keep a list of children there, along with a marker for the "active" child. > * Assuming CUC and CUDC are abandoned as I suggest in [1], and replaced > with the walk-widgets/update-uri-tokens semantics implemented there, > it ought to be specified that all you need to have a selector widget > is to implement get-widget-for-tokens and update-uri-tokens for your > widget class, and subclassing selector is unnecessary (although > convenient, as selector has a reasonable update-uri-tokens > implementation). I can't comment on the walk-widgets thing as I haven't seen it yet... I really wanted to get rid of the selector class, but could not. In fact it was gone at one point, but came back, because of container-update-direct-children. It represents an interface between widget tree updating and the get-widget-for-tokens method, and that interface is common to all selectors. Some implement a static mapping (static-selector), some export the get-widget-for-tokens externally (on-demand-selector). I believe there should be a single place where we call the mapping function, deal with widgets that are created (plug them into the tree) and maintain the current url. I do not want to have url-building and tree-maintaining code all over the place, that way lies madness. Hence the container-update-direct-children and update-dependents functions in selector.lisp on my navigation-rewrite branch. I think we are talking about very similar things. I am not at all attached to selector or container being there if there is a more sensible place for their functionality. (I am, however, against using generators, as I described elsewhere) > * Question: Is a selector required to render its selected widget? A good question (as usually) :-) I am not sure about the answer. I will be once I finish implementing the split navigation, where a descendant of static-selector will render the menu, but will also select a widget elsewhere in the tree. For the moment, I *think* the answer is "yes", as both selectors in that case will render their widgets (one is a menu and the other is the content). --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 -~----------~----~----~----~------~----~------~--~---
