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 Mon, 08 Aug 2016 15:29:23 GMT
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 <aharui@adobe.com> wrote:

> On 8/8/16, 7:54 AM, "Harbs" <harbs.lists@gmail.com> 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 <joshtynjala@gmail.com> 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 <harbs.lists@gmail.com> 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 <aharui@adobe.com> wrote:
>>>>> On 8/7/16, 2:08 PM, "Harbs" <harbs.lists@gmail.com> 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
>>>>>>> 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

View raw message