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" <joshtynj...@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" <aha...@adobe.com.invalid> wrote:
On 5/21/17, 1:38 AM, "yishayw" <yishayj...@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
