Stephen Compall <[email protected]> writes: > Jan Rychter <[email protected]> writes: >> 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? > > It is not quite the same. Non-containers can have and render children; > this is what MWPW is for. From a refactoring I did yesterday (uses > SERIES, note this is in a project with a completely different > `walk-widgets' interface): [...]
Please say you are not planning to make weblocks use SERIES... (Yes, I do know what SERIES is, in fact I have used it in the past, and more importantly, debugged software that used it, which influences my perception of it significantly) >> 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. > > One of the things I do is rename `container-children' to > `widget-children'. However, the intention is not that all children must > be answered from that method; that is what `generate-subwidgets' is > for. Instead, `widget-children' is *only* for a settable list of such > children, and has no backing slot on widget; all container still > provides is a slot with :accessor and an MWPW method. > >> 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. > > Which I do differently, without CUC and CUDC, with the help of widget > tree walking. Having just looked at your changes: I like the walk-widgets function. But even though it looks simpler than my two tree-walking methods, you still need to provide it with a function (or a method) that will be able to deal with all our widget types (widgets, strings, functions, and symbols I think). What I don't understand about your design is why you keep juggling the children list as if pretending it isn't stored anywhere. It does need to be stored somewhere. We can avoid having a slot for it, instead specifying a method, but the implementor will need to get the list of subwidgets from *somewhere*. We can juggle all we want, but the information has to be stored by someone at some point. And if it is, we might as well provide a place for it, along with a suitable abstraction. Am I missing something here? Plus, I am still very much against using generators. It's not like we'll have infinite lists of widgets and need lazy evaluation, so generators buy us no benefit that I can see, while introducing additional complexity. On a related note, I think the update-uri-tokens function is misnamed. It doesn't update any tokens. What it does is (in your tree, according to the docstring): "Looks up and returns the widget in the cache based on the tokens." in my tree it is called 'get-widget-for-tokens', which I think is a much more appropriate name. It gets you a widget for given tokens. And I don't think caching has anything to do with the specification, it's an implementation issue. >>> * Question: Is a selector required to render its selected widget? >> >> 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). > > Actually, I think this makes the answer "no", because the menu one > *doesn't* render the selected widget. I will be implementing a menu whose menu items will be widgets, so in this case it will select a widget. But not all menus will, so I don't think this is a requirement. > Anyway, if the answer is yes, I think the cache ought to mve back into > selector, since for all selectors there is the notion of a selected and > to-be-rendered widget. Even if the answer were yes, I would not agree -- because then all selectors would have a notion of a selected widget, not of a widget cache with all its management. That's a significant difference. In 99% of my selecting needs I don't use a cache. --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 -~----------~----~----~----~------~----~------~--~---
