On Feb 17, 11:12 am, Jan Rychter <[email protected]> wrote: > Vyacheslav Akhmechet <[email protected]> writes:
> > 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. That's what I thought when I read it. > 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. It wouldn't be hard to do this. I'm fond of the idea of storing widgets in slots, the children-of-type seems a bit clumsy in comparison. Are there any other disadvantages of using slots for children? > I really don't like mixing additional session hashmaps into that. +1. I also think that a tree is the only appropriate structure for Weblocks. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
