FlexJS MXML ids and classNames

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FlexJS MXML ids and classNames

Harbs
I thought that by adding an id and/or a className to MXML, that would set the id and class of a div, but it appears that it’s strictly an MXML property. Is that how it’s supposed to work?

I also noticed that setting the className of a UIBase sets the class of the element, but setting the id does not set the element id. That does not seem right to me. Any reason to not add the id to the element as well?

Harbs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Alex Harui


On 8/7/16, 4:09 AM, "Harbs" <[hidden email]> wrote:

>I thought that by adding an id and/or a className to MXML, that would set
>the id and class of a div, but it appears that it’s strictly an MXML
>property. Is that how it’s supposed to work?

Not sure I understand.  What do you mean by "MXML property"?

>
>I also noticed that setting the className of a UIBase sets the class of
>the element, but setting the id does not set the element id. That does
>not seem right to me. Any reason to not add the id to the element as well?

I agree it should set it on the element.

Thanks,
-Alex

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Andy Dufilie
In reply to this post by Harbs
On Sun, Aug 7, 2016 at 7:09 AM, Harbs <[hidden email]> wrote:

> I also noticed that setting the className of a UIBase sets the class of
> the element, but setting the id does not set the element id. That does not
> seem right to me. Any reason to not add the id to the element as well?
>

In MXML, the "id" property is used as an object property name so that an
MXML element can be accessed as a property of the containing MXML component
instance. For example, if your component is defined as <VBox><Button
id="a"/></VBox> you can have multiple instances of that component and the
buttons can be accessed as instance1.a, instance2.a. In HTML, the "id"
property of an element allows you to access that element globally like
document.getElementById("a").  If the cross-compiled MXML set the "id"
property of the resulting DOM elements, it would prevent
document.getElementById() from working correctly in websites where you wish
to embed a FlexJS application.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Harbs
OK. That makes sense. (and yes, you understood me correctly)

I do think that className should be assigned to the element though via MXML, and there should be an “element id” which should be set-able via MXML.

 “id” is important if you want some external code to be able to address a piece of your FlexJS app. It’s also important for setting styles via CSS.

On Aug 7, 2016, at 6:02 PM, Andy Dufilie <[hidden email]> wrote:

> On Sun, Aug 7, 2016 at 7:09 AM, Harbs <[hidden email]> wrote:
>
>> I also noticed that setting the className of a UIBase sets the class of
>> the element, but setting the id does not set the element id. That does not
>> seem right to me. Any reason to not add the id to the element as well?
>>
>
> In MXML, the "id" property is used as an object property name so that an
> MXML element can be accessed as a property of the containing MXML component
> instance. For example, if your component is defined as <VBox><Button
> id="a"/></VBox> you can have multiple instances of that component and the
> buttons can be accessed as instance1.a, instance2.a. In HTML, the "id"
> property of an element allows you to access that element globally like
> document.getElementById("a").  If the cross-compiled MXML set the "id"
> property of the resulting DOM elements, it would prevent
> document.getElementById() from working correctly in websites where you wish
> to embed a FlexJS application.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Alex Harui


On 8/7/16, 9:46 AM, "Harbs" <[hidden email]> wrote:

>OK. That makes sense. (and yes, you understood me correctly)
>
>I do think that className should be assigned to the element though via
>MXML, and there should be an “element id” which should be set-able via
>MXML.
>
> “id” is important if you want some external code to be able to address a
>piece of your FlexJS app. It’s also important for setting styles via CSS.

I'm not sure why you are saying that className isn't assigned to the
element.  The className setter looks like it would.

Maybe we need an option about whether id gets set on the element.  Or
maybe elements in the main view get their ids set.  Andy is right about
MXML components, but lots of folks only have one instance of each MXML
component and expect CSS id selectors to work.

Thoughts?
-Alex

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Harbs

On Aug 7, 2016, at 11:47 PM, Alex Harui <[hidden email]> wrote:

>
>
> On 8/7/16, 9:46 AM, "Harbs" <[hidden email]> wrote:
>
>> OK. That makes sense. (and yes, you understood me correctly)
>>
>> I do think that className should be assigned to the element though via
>> MXML, and there should be an “element id” which should be set-able via
>> MXML.
>>
>> “id” is important if you want some external code to be able to address a
>> piece of your FlexJS app. It’s also important for setting styles via CSS.
>
> I'm not sure why you are saying that className isn't assigned to the
> element.  The className setter looks like it would.

Never mind. I was wrong about this.

> Maybe we need an option about whether id gets set on the element.  Or
> maybe elements in the main view get their ids set.  Andy is right about
> MXML components, but lots of folks only have one instance of each MXML
> component and expect CSS id selectors to work.
>
> Thoughts?

I would suggest having an additional elementID property and the element would only have an id assigned if it’s set.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Alex Harui


On 8/7/16, 2:08 PM, "Harbs" <[hidden email]> wrote:

>
>Never mind. I was wrong about this.
>
>> Maybe we need an option about whether id gets set on the element.  Or
>> maybe elements in the main view get their ids set.  Andy is right about
>> MXML components, but lots of folks only have one instance of each MXML
>> component and expect CSS id selectors to work.
>>
>> Thoughts?
>
>I would suggest having an additional elementID property and the element
>would only have an id assigned if it’s set.

Hmm. I don't think that would be obvious to CSS users.

Thinking about this some more, so what if we pass the id on to the element
and you create more than one element?  Apparently it won't blow up the
browser.  I'd still lean towards having an option to not set the element
id.  It might be doable at the document level.  Sort of the reverse of
what you suggested: if you set "dontSetElementIds" on the MXML top tag,
the MXMLDataInterpreter could set some other property like mxmlId instead
of id.

Thoughts?
-Alex

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Harbs
Browsers don’t blow up, but they arguably should…[1] ;-)

I’m not sure why “elementID” would be confusing.

The other way that I see doing it is to use “id” for the element id, and use some other property for the Flex “id” (uid maybe?)

I don’t like the idea of making it a compiler option or MXML tag.

[1]http://programmers.stackexchange.com/questions/127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really

On Aug 8, 2016, at 8:26 AM, Alex Harui <[hidden email]> wrote:

>
>
> On 8/7/16, 2:08 PM, "Harbs" <[hidden email]> wrote:
>>
>> Never mind. I was wrong about this.
>>
>>> Maybe we need an option about whether id gets set on the element.  Or
>>> maybe elements in the main view get their ids set.  Andy is right about
>>> MXML components, but lots of folks only have one instance of each MXML
>>> component and expect CSS id selectors to work.
>>>
>>> Thoughts?
>>
>> I would suggest having an additional elementID property and the element
>> would only have an id assigned if it’s set.
>
> Hmm. I don't think that would be obvious to CSS users.
>
> Thinking about this some more, so what if we pass the id on to the element
> and you create more than one element?  Apparently it won't blow up the
> browser.  I'd still lean towards having an option to not set the element
> id.  It might be doable at the document level.  Sort of the reverse of
> what you suggested: if you set "dontSetElementIds" on the MXML top tag,
> the MXMLDataInterpreter could set some other property like mxmlId instead
> of id.
>
> Thoughts?
> -Alex
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Josh Tynjala
Using id as the element id would probably lead to duplicate element ids
somewhat frequently, I suspect. Any time there are multiple instances of
the same component on screen, you'd have duplicates. In the worst case, a
custom item renderer where a sub-component has an id would result in many
duplicates.

- Josh

On Mon, Aug 8, 2016 at 4:38 AM, Harbs <[hidden email]> wrote:

> Browsers don’t blow up, but they arguably should…[1] ;-)
>
> I’m not sure why “elementID” would be confusing.
>
> The other way that I see doing it is to use “id” for the element id, and
> use some other property for the Flex “id” (uid maybe?)
>
> I don’t like the idea of making it a compiler option or MXML tag.
>
> [1]http://programmers.stackexchange.com/questions/
> 127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really
>
> On Aug 8, 2016, at 8:26 AM, Alex Harui <[hidden email]> wrote:
>
> >
> >
> > On 8/7/16, 2:08 PM, "Harbs" <[hidden email]> wrote:
> >>
> >> Never mind. I was wrong about this.
> >>
> >>> Maybe we need an option about whether id gets set on the element.  Or
> >>> maybe elements in the main view get their ids set.  Andy is right about
> >>> MXML components, but lots of folks only have one instance of each MXML
> >>> component and expect CSS id selectors to work.
> >>>
> >>> Thoughts?
> >>
> >> I would suggest having an additional elementID property and the element
> >> would only have an id assigned if it’s set.
> >
> > Hmm. I don't think that would be obvious to CSS users.
> >
> > Thinking about this some more, so what if we pass the id on to the
> element
> > and you create more than one element?  Apparently it won't blow up the
> > browser.  I'd still lean towards having an option to not set the element
> > id.  It might be doable at the document level.  Sort of the reverse of
> > what you suggested: if you set "dontSetElementIds" on the MXML top tag,
> > the MXMLDataInterpreter could set some other property like mxmlId instead
> > of id.
> >
> > Thoughts?
> > -Alex
> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Harbs
Agreed. That’s why I’m suggestion we using “elementID” instead.

On Aug 8, 2016, at 5:46 PM, Josh Tynjala <[hidden email]> wrote:

> Using id as the element id would probably lead to duplicate element ids
> somewhat frequently, I suspect. Any time there are multiple instances of
> the same component on screen, you'd have duplicates. In the worst case, a
> custom item renderer where a sub-component has an id would result in many
> duplicates.
>
> - Josh
>
> On Mon, Aug 8, 2016 at 4:38 AM, Harbs <[hidden email]> wrote:
>
>> Browsers don’t blow up, but they arguably should…[1] ;-)
>>
>> I’m not sure why “elementID” would be confusing.
>>
>> The other way that I see doing it is to use “id” for the element id, and
>> use some other property for the Flex “id” (uid maybe?)
>>
>> I don’t like the idea of making it a compiler option or MXML tag.
>>
>> [1]http://programmers.stackexchange.com/questions/
>> 127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really
>>
>> On Aug 8, 2016, at 8:26 AM, Alex Harui <[hidden email]> wrote:
>>
>>>
>>>
>>> On 8/7/16, 2:08 PM, "Harbs" <[hidden email]> wrote:
>>>>
>>>> Never mind. I was wrong about this.
>>>>
>>>>> Maybe we need an option about whether id gets set on the element.  Or
>>>>> maybe elements in the main view get their ids set.  Andy is right about
>>>>> MXML components, but lots of folks only have one instance of each MXML
>>>>> component and expect CSS id selectors to work.
>>>>>
>>>>> Thoughts?
>>>>
>>>> I would suggest having an additional elementID property and the element
>>>> would only have an id assigned if it’s set.
>>>
>>> Hmm. I don't think that would be obvious to CSS users.
>>>
>>> Thinking about this some more, so what if we pass the id on to the
>> element
>>> and you create more than one element?  Apparently it won't blow up the
>>> browser.  I'd still lean towards having an option to not set the element
>>> id.  It might be doable at the document level.  Sort of the reverse of
>>> what you suggested: if you set "dontSetElementIds" on the MXML top tag,
>>> the MXMLDataInterpreter could set some other property like mxmlId instead
>>> of id.
>>>
>>> Thoughts?
>>> -Alex
>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Alex Harui


On 8/8/16, 7:54 AM, "Harbs" <[hidden email]> wrote:

>Agreed. That’s why I’m suggestion we using “elementID” instead.

IMO, that's more work for the less-sophisticated scenario, which is why I
would propose the opposite (another variant of PAYG).  A "simple" app that
uses CSS id selectors that is going to be used to compare FlexJS against
other options probably should use "id" as expected.  What percentage of
your MXML components have multiple instances on-screen at one time?  For
those components, would it be painful to have to set an mxmlID property
instead of "id"?

Also, if you do use an MXML component twice, could the compiler someday
discover that?

Thanks,
-Alex

>
>On Aug 8, 2016, at 5:46 PM, Josh Tynjala <[hidden email]> wrote:
>
>> Using id as the element id would probably lead to duplicate element ids
>> somewhat frequently, I suspect. Any time there are multiple instances of
>> the same component on screen, you'd have duplicates. In the worst case,
>>a
>> custom item renderer where a sub-component has an id would result in
>>many
>> duplicates.
>>
>> - Josh
>>
>> On Mon, Aug 8, 2016 at 4:38 AM, Harbs <[hidden email]> wrote:
>>
>>> Browsers don’t blow up, but they arguably should…[1] ;-)
>>>
>>> I’m not sure why “elementID” would be confusing.
>>>
>>> The other way that I see doing it is to use “id” for the element id,
>>>and
>>> use some other property for the Flex “id” (uid maybe?)
>>>
>>> I don’t like the idea of making it a compiler option or MXML tag.
>>>
>>> [1]http://programmers.stackexchange.com/questions/
>>> 127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really
>>>
>>> On Aug 8, 2016, at 8:26 AM, Alex Harui <[hidden email]> wrote:
>>>
>>>>
>>>>
>>>> On 8/7/16, 2:08 PM, "Harbs" <[hidden email]> wrote:
>>>>>
>>>>> Never mind. I was wrong about this.
>>>>>
>>>>>> Maybe we need an option about whether id gets set on the element.
>>>>>>Or
>>>>>> maybe elements in the main view get their ids set.  Andy is right
>>>>>>about
>>>>>> MXML components, but lots of folks only have one instance of each
>>>>>>MXML
>>>>>> component and expect CSS id selectors to work.
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>> I would suggest having an additional elementID property and the
>>>>>element
>>>>> would only have an id assigned if it’s set.
>>>>
>>>> Hmm. I don't think that would be obvious to CSS users.
>>>>
>>>> Thinking about this some more, so what if we pass the id on to the
>>> element
>>>> and you create more than one element?  Apparently it won't blow up the
>>>> browser.  I'd still lean towards having an option to not set the
>>>>element
>>>> id.  It might be doable at the document level.  Sort of the reverse of
>>>> what you suggested: if you set "dontSetElementIds" on the MXML top
>>>>tag,
>>>> the MXMLDataInterpreter could set some other property like mxmlId
>>>>instead
>>>> of id.
>>>>
>>>> Thoughts?
>>>> -Alex
>>>>
>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Harbs
I don’t get it.

Why is having MXML tags the opposite?

I don’t like the idea of having one property used for two very different things. I think that’s more confusing than requiring a slightly non-standard name.

On Aug 8, 2016, at 6:12 PM, Alex Harui <[hidden email]> wrote:

>
>
> On 8/8/16, 7:54 AM, "Harbs" <[hidden email]> wrote:
>
>> Agreed. That’s why I’m suggestion we using “elementID” instead.
>
> IMO, that's more work for the less-sophisticated scenario, which is why I
> would propose the opposite (another variant of PAYG).  A "simple" app that
> uses CSS id selectors that is going to be used to compare FlexJS against
> other options probably should use "id" as expected.  What percentage of
> your MXML components have multiple instances on-screen at one time?  For
> those components, would it be painful to have to set an mxmlID property
> instead of "id"?
>
> Also, if you do use an MXML component twice, could the compiler someday
> discover that?
>
> Thanks,
> -Alex
>
>>
>> On Aug 8, 2016, at 5:46 PM, Josh Tynjala <[hidden email]> wrote:
>>
>>> Using id as the element id would probably lead to duplicate element ids
>>> somewhat frequently, I suspect. Any time there are multiple instances of
>>> the same component on screen, you'd have duplicates. In the worst case,
>>> a
>>> custom item renderer where a sub-component has an id would result in
>>> many
>>> duplicates.
>>>
>>> - Josh
>>>
>>> On Mon, Aug 8, 2016 at 4:38 AM, Harbs <[hidden email]> wrote:
>>>
>>>> Browsers don’t blow up, but they arguably should…[1] ;-)
>>>>
>>>> I’m not sure why “elementID” would be confusing.
>>>>
>>>> The other way that I see doing it is to use “id” for the element id,
>>>> and
>>>> use some other property for the Flex “id” (uid maybe?)
>>>>
>>>> I don’t like the idea of making it a compiler option or MXML tag.
>>>>
>>>> [1]http://programmers.stackexchange.com/questions/
>>>> 127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really
>>>>
>>>> On Aug 8, 2016, at 8:26 AM, Alex Harui <[hidden email]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 8/7/16, 2:08 PM, "Harbs" <[hidden email]> wrote:
>>>>>>
>>>>>> Never mind. I was wrong about this.
>>>>>>
>>>>>>> Maybe we need an option about whether id gets set on the element.
>>>>>>> Or
>>>>>>> maybe elements in the main view get their ids set.  Andy is right
>>>>>>> about
>>>>>>> MXML components, but lots of folks only have one instance of each
>>>>>>> MXML
>>>>>>> component and expect CSS id selectors to work.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>
>>>>>> I would suggest having an additional elementID property and the
>>>>>> element
>>>>>> would only have an id assigned if it’s set.
>>>>>
>>>>> Hmm. I don't think that would be obvious to CSS users.
>>>>>
>>>>> Thinking about this some more, so what if we pass the id on to the
>>>> element
>>>>> and you create more than one element?  Apparently it won't blow up the
>>>>> browser.  I'd still lean towards having an option to not set the
>>>>> element
>>>>> id.  It might be doable at the document level.  Sort of the reverse of
>>>>> what you suggested: if you set "dontSetElementIds" on the MXML top
>>>>> tag,
>>>>> the MXMLDataInterpreter could set some other property like mxmlId
>>>>> instead
>>>>> of id.
>>>>>
>>>>> Thoughts?
>>>>> -Alex
>>>>>
>>>>
>>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Alex Harui


On 8/8/16, 8:29 AM, "Harbs" <[hidden email]> wrote:

>I don’t get it.
>
>Why is having MXML tags the opposite?
>
>I don’t like the idea of having one property used for two very different
>things. I think that’s more confusing than requiring a slightly
>non-standard name.

I might be missing something, but I would introduce an mxmlID property
that would do what "id" currently does.  The "id" property would set both
mxmlID and id on the element.  That way, using "id" in MXML and CSS works
in simple cases. The compiler would generate slots in the document for
both "id" and mxmlID.  If you plan to have multiple instances of an
MXMLComponent, use "mxmlID" instead of "id".

I'm still pondering whether the top tag in an MXML file could determine
whether id gets set on the element or not.  The cool thing about MXML in
FlexJS is that it generates a data structure instead of code, so the
MXMLDataInterpreter could see that the "id" property is being set and do
something different.  If there are ItemRenderer base classes that are used
in MXML item renderers, they could set a flag so that MXMLDataInterpreter
sets mxmlID instead of "id" or otherwise tells the child component to not
set the element's id.  I also wonder if FlexJS should translate id
selectors to class selectors automatically.  We do that to extend the Type
Selectors already.

Thoughts?
-Alex

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Harbs
Ah. I did not understand you.

So you are saying that if you don’t care about multiple IDs (or are making sure your IDs are unique, you can just use id. If you don’t want the MXML id to propagate to the DOM, you’d use mxmlID for the MXML instead.

Did I get it?

>  I also wonder if FlexJS should translate id
> selectors to class selectors automatically.  We do that to extend the Type
> Selectors already.

I did not understand this.

On Aug 8, 2016, at 7:49 PM, Alex Harui <[hidden email]> wrote:

>
>
> On 8/8/16, 8:29 AM, "Harbs" <[hidden email]> wrote:
>
>> I don’t get it.
>>
>> Why is having MXML tags the opposite?
>>
>> I don’t like the idea of having one property used for two very different
>> things. I think that’s more confusing than requiring a slightly
>> non-standard name.
>
> I might be missing something, but I would introduce an mxmlID property
> that would do what "id" currently does.  The "id" property would set both
> mxmlID and id on the element.  That way, using "id" in MXML and CSS works
> in simple cases. The compiler would generate slots in the document for
> both "id" and mxmlID.  If you plan to have multiple instances of an
> MXMLComponent, use "mxmlID" instead of "id".
>
> I'm still pondering whether the top tag in an MXML file could determine
> whether id gets set on the element or not.  The cool thing about MXML in
> FlexJS is that it generates a data structure instead of code, so the
> MXMLDataInterpreter could see that the "id" property is being set and do
> something different.  If there are ItemRenderer base classes that are used
> in MXML item renderers, they could set a flag so that MXMLDataInterpreter
> sets mxmlID instead of "id" or otherwise tells the child component to not
> set the element's id.  I also wonder if FlexJS should translate id
> selectors to class selectors automatically.  We do that to extend the Type
> Selectors already.
>
> Thoughts?
> -Alex
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Alex Harui


On 8/8/16, 10:24 PM, "Harbs" <[hidden email]> wrote:

>Ah. I did not understand you.
>
>So you are saying that if you don’t care about multiple IDs (or are
>making sure your IDs are unique, you can just use id. If you don’t want
>the MXML id to propagate to the DOM, you’d use mxmlID for the MXML
>instead.
>
>Did I get it?

Yes.

>
>>  I also wonder if FlexJS should translate id
>> selectors to class selectors automatically.  We do that to extend the
>>Type
>> Selectors already.
>
>I did not understand this.

Apparently, an issue with id selectors is that you really are only
supposed to have a single element with that id in the DOM.  I think I read
that some folks translate id selectors to class selectors and assign
className instead of id so you can have more than one element respond to
those styles.

-Alex

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Harbs

>
> Apparently, an issue with id selectors is that you really are only
> supposed to have a single element with that id in the DOM.  I think I read
> that some folks translate id selectors to class selectors and assign
> className instead of id so you can have more than one element respond to
> those styles.

There are definitely cases where you want to use ids instead of classes (i.e. when you really want to target a specific element). I don’t think we should mess with that.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

piotrz
In reply to this post by Alex Harui
Hi Alex,

Where this discussion end up? It seems that your proposition was reasonable.

Hi Harbs,

You wasn't convinced about that additional tag "mxmlID" ? Am I understand right ?

Piotr
Apache Flex PMC
piotrzarzycki21@gmail.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Justin Mclean
Administrator
Hi,

If you make a component with something with an id in it and then use that multiple times in the same view (which is common pattern comping from the Flex world) are you going to run into this issue?

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

Alex Harui-2


On 5/20/17, 3:17 PM, "Justin Mclean" <[hidden email]> wrote:

>Hi,
>
>If you make a component with something with an id in it and then use that
>multiple times in the same view (which is common pattern comping from the
>Flex world) are you going to run into this issue?

AIUI, it depends on if any code cares (expects one and only one component
with an id).  

So the proposal is to support a new property called "mxmlID" that can be
used to find objects in an MXML document but does not set the
HTMLElement's id property.  IMO, the proposal needs more discussion.

In more detail, for the following file:

    ---- Foo.mxml ----
    <SomeBaseClass>
      <SomeClass id="bar" />
    </SomeBaseClass>

The compiler creates a property in Foo called "bar".  Then in ActionScript
you can write "bar.someProperty".  It worked this way in regular Flex as
well, and pretty much eliminated any need for a "getElementByID" API.

In the JS output for FlexJS, the HTMLElement "id" is also set to "bar.
This enables ID selectors in CSS.  But you are not supposed to have more
than one HTMLElement with the same id.  Although my understanding is that
the browsers will not care, but library code like in MDL might.

So, if someone does:

    ---- Baz.mxml ----
    <SomeBaseClass>
      <Foo />
      <Foo />
    </SomeBaseClass>

There still isn't a getElementByID call in FlexJS, so everyone writing
"bar.someProperty" is just fine.  But underneath, the browser now sees two
HTMLElements with id == "bar" and third-party JS library code calling
document.getElementByID is going to get the first instance and can't get
to the second one.


The proposal is for someone to write instead:
    ---- Foo.mxml ----
    <SomeBaseClass>
      <SomeClass mxmlID="bar" />
    </SomeBaseClass>

The compiler will still create a property in Foo called "bar" and in AS
you can still write "bar.someProperty".  I'm trying to think of what else
will be impacted by allowing this.


Thoughts?
-Alex

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS MXML ids and classNames

piotrz
In reply to this post by Justin Mclean
Hi Justin,

I just checked and yes I'm running into exactly same issue.

Piotr
Apache Flex PMC
piotrzarzycki21@gmail.com
123
Loading...