Vyacheslav Akhmechet <[email protected]> writes: > Actually, since people mostly keep child widgets in slots because they > need to access them individually, it would be cool to provide a > hashmap/association list interface so that one could get and set child > widgets in a widget by name: > > (setf (child-widget parent-widget 'child-name) child-widget) > (child-widget parent-widget 'child-name) > > And of course one could implement (child-widgets parent-widget).
Hmm. But how is that different from get-children-by-type? (except for the fact that you can have only one child widget per name, which is a limitation I would not be happy with) The above interface looks almost exactly like what I implemented, just change the names. As I wrote before, I do not think storing widgets in slots is a good idea at all, because by default they can't participate in flows. This could change if someone hacks a general make-widget-place-writer for widget slots. > This association can be stored in a per-session hashmap, not widget > slots, so it would avoid the multiple inheritance issue. The benefit > is that one could easily store and access child widgets as one does > with slots, which is immensely useful, without having to use an > additional interface to specify the child widgets for weblocks > machinery. I really don't like mixing additional session hashmaps into that. We already have a data structure intended to hold widgets: it's the widget tree. I don't think multiplying data structures is a good idea. If the widget tree doesn't serve its purpose, let's get rid of the widget tree and replace it with something else, but let's not have two structures in parallel. --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 -~----------~----~----~----~------~----~------~--~---
