flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: FlexJS MXML ids and classNames
Date Sun, 21 May 2017 16:12:32 GMT
Going along these lines:

id could have the same behavior as today.
localID could only apply to the mxml.
globalID could only apply to the HTML and would be checked by the compiler for uniqueness.

> On May 21, 2017, at 11:59 AM, Josh Tynjala <joshtynjala@gmail.com> wrote:
> I'm thinking my proposal of the name globalID is better than htmlID.
> Calling it globalID would allow us to use it on the SWF side too. For
> instance, someone could write some kind of utility function that provides
> functionality similar to document.getElementById() that works
> cross-platform to return a FlexJS component.
> - Josh
> On May 21, 2017 8:44 AM, "Josh Tynjala" <joshtynjala@gmail.com> wrote:
> The more I think about it, the more I think we should keep the semantics of
> id MXML-centric. It should create a member variable on the class like it
> always has, but it should not set the id on the HTML element. Instead, we
> should add a separate property for the HTML element's id. Maybe htmlID,
> maybe globalID.
> Let's not change a core behavior of id in the MXML language. MXML id has
> been established to mean something in Flex (and Feathers too!) for over a
> decade. Let's not break that without a better reason. An MXML file will
> mostly contain high level components, rather than wrappers for specific
> HTML elements (even if there are some), so I think it's fair to expect
> developers to think in a different context for MXML and understand that id
> in MXML doesn't translate to id in HTML.
> - Josh
> On May 21, 2017 7:58 AM, "Alex Harui" <aharui@adobe.com.invalid> wrote:
> On 5/21/17, 1:38 AM, "yishayw" <yishayjobs@hotmail.com> wrote:
>> I like the idea. Sencha follows a similar pattern as far as I remember. I
>> don't like mxmlID. Everything in MXML is MXML. I would go with 'localId',
>> for the one that doesn't translate to HTML, and 'id' for the one that
>> does.
>> Also, there's nothing preventing an AS3 class from accessing the so called
>> 'mxmlID'.
> I don't care too much what we call this property, but I cannot think of a
> scenario where someone would write 'mxmlID' from an AS3 class.  Instead, I
> think you will always access the referenced object by its assigned name.
> IOW:
>    ---- Foo.mxml ----
>    <SomeBaseClass>
>        <SomeClass mxmlID="bar" someProperty="baz" />
>    </SomeBaseClass>
> Means that you will write "bar.someProperty".  In fact, it might be
> possible for "mxmlID" or "localID" to be a pseudo-property and not
> actually a property on the object.  We already do this for "includeIn" and
> "excludeFrom" in states.  These properties are truly MXML-only and not
> ever set on the object.
> If we want to be more descriptive, we could call it "documentID" or even
> "documentVariableName" or "mxmlDocumentVariableName" which is actually
> what it does.
> Thoughts?
> -Alex

View raw message