Leslie, This is an old message and some dialog from when we decided to implement this. The idea was to provide a more flexible interface that allowed us to do flows on sub-object of a container without having to have a proliferation of composites. Is container simply a refactoring of composites to an interface?
Does the container interface provide this same level of flexibility? Here was my original proposal: ------------------------------ - Generalized composites do-widget uses a generic function (setf (widget-place container old- widget new-widget) ...) Re-implement call/answer & do-widget in terms of (setf widget-place). This allows us to make any object a container by implementing the method. Composite objects continue use the rplaca method to update the list, but any object can implement this method to replace an active widget. For example I could implement a method that searches several class slots for a matching widget and replaces it. Stephen's response: ------------------- Combining the functionality of the first with the optimization of the second, we could have only gf WIDGET-PLACE (container old-widget) that returns a function that puts its argument in the place if there is one, otherwise returning the place's current value. Or two functions. This avoids the search without introducing an additional notion. Slava: ------ The container is here for the purpose of dispatch, correct? (We can always obtain the container by grabbing the parent of the old-widget, which implies that maintaining the parent of widgets must be a part of the contract setf widget-place must fulfill). If this is so, I think this is a good idea. On Aug 24, 2008, at 5:27 PM, Stephen Compall wrote: > > Ian Eslick <[EMAIL PROTECTED]> writes: >> Sorry on the debug stmt. > > :) > > https://www.bitbucket.org/coffeemug/weblocks-dev/changeset/ > b2adc22d0e9d > >> I'll look at your comments and add a follow-up patch. I'm also going >> to add a place writer to the default navigator so you can perform >> flows on navigator panes without having to wrap each pane in a >> composite. > > Great, exactly what I was looking for when writing a flow yesterday :) > >> That was one of the early confusions I had. Any 'widget container' >> should support flows on an object it contains. > > Would it be fair to say that for every widget, the set of children > answered by composite-widgets is equal to the set of children that can > be given to make-widget-place-writer with that widget? > > If so, dispatcher needs to take care to notice ephemerality (see r775 > and r776) when calculating children and places. > > -- > 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 -~----------~----~----~----~------~----~------~--~---
