Jan Rychter <[email protected]> writes: > Please say you are not planning to make weblocks use SERIES...
Not even a little. But it might end up required by my contribs, because I really like the little MWPW helper defined for that code. > 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). For the simple widgetp case, this is straightforward. For generic functions, I defined something to help users write new universal-widget operating GFs in dev, but it only works in Clozure thanks to my ignorance of the semantics of method-functions. > 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? Yes, I have discussed this previously in http://groups.google.com/group/weblocks/msg/0e5993f23843b7b8 , as well as elsewhere in that thread. There are two notions at work here: * The *settable* list of subwidgets, defined by widget-children. This is important because these are *not composable*. * A superset of this list is the widget-intrinsic list of subwidgets. This doesn't affect rendering, and is only there to give the tree a full structure. In my modern-dispatching, this is implemented with generate-subwidgets. In HFSBO and that post above, it is implemented using `walk-widgets' (not to be confused with the pure-function walk-widgets in my modern-dispatching). Also, MWPW operates on this list, not the first one. Let us say that you define two widgets that hold onto 3 subwidgets each to do their work. Then you wish to compose them with multiple inheritence. If you do (setf widget-children) in initialize-instance, you lose the 3 from one of them depending on CPL order. If you append to (setf widget-children), the order depends on CPL, so when trying to access a subwidget, each widget's methods must be type-sensitive (and hope their types don't clash with the other mixins) or understand that mixing-in may alter the list positions of "it's" subwidgets. If you track by both appending to (setf widget-children) and storing in a slot, you must take care to follow every change to a child-holding slot with a SUBSTITUTE on and (setf widget-children). There are many circumstances where altering a list is even more error-prone than this. The big widget on http://www.hfsbo.com/services-and-pricing is a listedit with: (defmethod walk-widgets progn (proc (self available-contract-browser)) "Include all current interval browsers." (maphash #L(walk-widgets proc !2) (slot-value self 'interval-browsers))) Without the above method, the interval-browsers (the little gridedits below each item) could not be altered when authentication information changes. Interval-browsers is, incidentally, lazily updated by a render-object-view-impl method that is also responsible for rendering. If I had to store these in a separate list, I would have to be sensitive to pagination myself, instead of letting whoever calls ROVI figure it out for me. The available-contract-browser, incidentally, *does* use subwidget composition; the ACB method walks into the interval browsers, and the dataedit-mixin walks into the dataedit-item-widget if it is present. So the list of subwidgets (the second notion) *isn't* stored anywhere, though of course the subwidgets themselves are, but it *is* accessible to all code via `generate-subwidgets', or rather, whatever replaces that. On a side note, this is another naming problem. I have been calling the first notion "children" and the second "subwidgets". > 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. I was more thinking of the cost of repeated `append' operations as multiple users walk the widget tree in code. If you think this cost will be insignificant, then it probably will be. > 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. You are probably right, but I would like to see one more thing: outside a request, when the URI is no longer available, how would code with a reference to such a selector determine which is the selected widget, without having specific knowledge of what subclass of selector it is? -- I write stuff at http://failex.blogspot.com/ now. But the post formatter and themes are terrible for sharing code, the primary content, so it might go away sooner or later. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
