If we had more time, MXML would generate the adding of a bead. Then you could
use just about any class in MXML.
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.
Unfortunately, ListBase currently subclasses GroupBase but is a control.
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.
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?
