I think there are two separate issues. "Proxy and Wrappers" and "Content
Areas".
Panel and ScrollingViewports on certain platforms require "Content Areas",
a separate DOM widget that actually holds the children. Right now we
override addElement and add a $addElement. I think that's probably as
Maybe I'm misunderstanding again.
This is what a developer should do so that the contents of the panel are
laid out horizontally.
I constructed Panel as a subclass of Group so that I could take advantage
of VerticalFlexLayout so that Container content area of the Panel would
grow to
Yes, thanks for removing unnecessary coercions.
While debugging examples, I also noted the removal of Layout in Panel.
Makes me wonder if we our container architecture/lifecycle is designed
properly. The base classes may need to have a pattern for "proxies" and
"wrappers", which may be the essenc
I happened to be testing against FlexJSStore at the time I discovered the
need for this, and there is some removing going on.
I think I improved performance compared to how it was originally by
removing coercion in js and using local references for some of the repeat
listener references/avoiding r
I guess I don't believe that removing beads is so common that every app
needs to carry this code around. I wonder if there is a way to inject
removability as needed.
Having a RemovableXXXLayout could override the strand setter and remove
listeners if the handlers are protected.
Thoughts?
-Alex
