I’m not sure who originally based HTML element off Group, but all I did (when I
worked on completing the HTML component set) was to simplify the classes and
complete set. Admittedly, not all of them based Group originally, but I think
that was an oversight. I can’t think of any HTML elements which can’t contain
others.
I don’t have a strong opinion regarding states and transitions, but I think the
answer to that depends on how “core” that functionality is to MXML. My leaning
is that at least states is pretty “core” and if an MXML file has states, all
the children :containers” should in turn support them. I think that should
include HTML elements. It seems pretty reasonable to be able to do something
like this:
<html:Span id="nameText" text.loggedin="Hi {NAME}" text.loggedout="Please log
in."/>
I’m not sure why transitions is part of Group, so I don’t have anything
intelligent to say there.
Harbs
> On May 10, 2018, at 10:48 AM, Alex Harui <[email protected]> wrote:
>
> 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" <[email protected]> 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 <[email protected]> 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?
>
>
>
