Hi Alex,
2018-05-10 9:48 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > If we had more time, MXML would generate the adding of a bead. Then you > could use just about any class in MXML. > I think that would be very good, since will make royale more consistent right? > > Having something support being an MXML root tag requires the APIs in Group > that call MXMLDataInterpreter at the two points in the lifecycle, and in > most cases an "mxmlContent" property referenced by the [DefaultProperty] > metadata. > > Yes, you can say that MXML also requires addElement and States requires a > states property and addElementAt, removeElement, but those APIs are > available on most base classes anyway. > > I think that's it, although I may be forgetting something. > > Group is supposed to be the simplest "container" that supports assignable > layout. If we do a major refactor I would probably push to rename it to > Container and call Container something else like > ContainerWithWrappedContent. In Royale I wanted us to have a clear > distinction between controls and containers and it isn't clear that Group > is a "container", but not a Container (org.apache.royale.html). While > UIBase has an addElement/removeElement API, I also hoped to tweak ASDoc to > hide those APIs from application developers. The component/library > developer needs to use addElement to construct a complex component, but the > application developer should not be calling addElement on controls, only on > containers. And the application developer should not be using what is now > Container unless they need to wrap the children to add fancy borders, > titlebars and other chrome. > I still does not understand why we have Group and Container, I think Peter said that was due to SWF needs, but as in other parts of the SDK we should not have classes of general purpose if the motivation is serve one concrete output (in this case SWF). > > Unfortunately, ListBase currently subclasses GroupBase but is a control. > But in a refactor that's seems right to refactor right? > > IMO, you have to look at what the value add is of each class in order to > decide what to use for a base class. It isn't clear that "HTML" > components need to support states and transitions, for example. > I'm with Harbs that HTML should support states and transitions (and transitions maybe most for SWF needs, since in HTML transitions are all in CSS, and maybe that should be the same for CSS...) > > My 2 cents, > -Alex > > > On 5/9/18, 11:31 PM, "Harbs" <harbs.li...@gmail.com> wrote: > > I don’t care that it should extend Group specifically, but it does > need to extend (or implement) a "Group-esque” component. Without that, HTML > element components can’t contain other elements in MXML. > > Which pieces are required for it to contain other elements in MXML? > Not 100% sure about that. > > As far as what it needs? Not 100% sure but definitely: > addElement > addElementAt > removeElement > > Pretty sure about DefaultProperty. > > Not sure about: > Layout pieces > States > Transitions > IMXMLDocument > > Various events? Dunno. > > I’d guess that Layout is probably something we *do* want to have. > Requiring that to be specified using standard css doesn’t feel very > “Royale-like” to me. > States should likely be included as well to allow HTML elements to be > modified by states. > I don’t know why Transitions are included in Group in the first place, > so I can’t comment on that. > > IMXMLDocument: Is that needed only for making it a base for an MXML > file? Should HTML Element components have the ability to be used as a base > for MXML? I don’t know the answers to this. > > Harbs > > > On May 10, 2018, at 2:19 AM, Alex Harui <aha...@adobe.com.INVALID> > wrote: > > > > On the other hand, I don't agree with Yishay's and Harb's concerns > about the NodeElementBase having to subclass Group in order to get MXML > children. The ability to specify children in MXML can be added to any > class. What else does NodeElementBase.as use from Group/GroupBase? > > > > -- Carlos Rovira http://about.me/carlosrovira
