You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2016/08/07 11:09:54 UTC
FlexJS MXML ids and classNames
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
Re: FlexJS MXML ids and classNames - FLEX-35310
Posted by piotrz <pi...@gmail.com>.
Hi Alex,
Ok for me personally that's not the problem. I will create that Bead as an
addition which helps with that bug.
Adding "localId" without touching "id" it can also satisfy my needs and
application which was touched by that problem.
I would be happy if other opinion appear on that issue.
Thanks,
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p63338.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames - FLEX-35310
Posted by piotrz <pi...@gmail.com>.
Alex,
Issue #2 is fixed. As for the issue #1 I also don't know how code
intelligence is working - maybe Josh will see the post and shed some light
on that.
Thank you!
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p63919.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames - FLEX-35310
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I will have to do more investigation for #1. I don't know if magic
properties are the responsibility of the compiler or the IDE's code
intelligence.
I just pushed a change for #2. It should be using "_id" (with leading
underscore) instead of "id".
Thanks for catching that,
-Alex
On 8/17/17, 10:31 PM, "piotrz" <pi...@gmail.com> wrote:
>Hi Alex,
>
>Finally I have found cycle to look into your changes. I've used for tests
>example from jira.
>
>1) localId is not visible in code completion in Moonshine and Intellij -
>However everything is building fine. - SDK has been downloaded by
>installer.
>
><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>ex-development.2333347.n4.nabble.com%2Ffile%2Fn63903%2Fdouble_id_moonshine
>_view.png&data=02%7C01%7C%7C7aa8e81767134cc1493e08d4e5fabfce%7Cfa7b1b5a7b3
>4438794aed2c178decee1%7C0%7C0%7C636386312502891401&sdata=v1k44KkOoNyQPJcCU
>AOKWKONnw7acsIdN45JVrTnjxE%3D&reserved=0>
>
>2) Once I build project and look into generated HTML I see that localId
>has
>been transformated to "id". I think it shouldn't be like that. Am I
>understand it wrong ?
>
><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>ex-development.2333347.n4.nabble.com%2Ffile%2Fn63903%2Flocal_id.png&data=0
>2%7C01%7C%7C7aa8e81767134cc1493e08d4e5fabfce%7Cfa7b1b5a7b34438794aed2c178d
>ecee1%7C0%7C0%7C636386312502891401&sdata=sADvMFVGheLKLG59eJTs41nRNohYBF8jb
>eImPfC7GK0%3D&reserved=0>
>
>Thanks,
>Piotr
>
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.2333347.n4.nabble.com%2FFlexJS-MXML-ids-and-classNames-tp543
>61p63903.html&data=02%7C01%7C%7C7aa8e81767134cc1493e08d4e5fabfce%7Cfa7b1b5
>a7b34438794aed2c178decee1%7C0%7C0%7C636386312502891401&sdata=c7l5kS5sQAUPl
>2fP0Xd7ICFg9ZqtgV3SEKnCLj2KVIM%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames - FLEX-35310
Posted by piotrz <pi...@gmail.com>.
Hi Alex,
Finally I have found cycle to look into your changes. I've used for tests
example from jira.
1) localId is not visible in code completion in Moonshine and Intellij -
However everything is building fine. - SDK has been downloaded by installer.
<http://apache-flex-development.2333347.n4.nabble.com/file/n63903/double_id_moonshine_view.png>
2) Once I build project and look into generated HTML I see that localId has
been transformated to "id". I think it shouldn't be like that. Am I
understand it wrong ?
<http://apache-flex-development.2333347.n4.nabble.com/file/n63903/local_id.png>
Thanks,
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p63903.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames - FLEX-35310
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I pushed some code that tries to implement a "localId" property. It
seemed to work in a simple test.
-Alex
On 8/3/17, 10:58 AM, "piotrz" <pi...@gmail.com> wrote:
>Hi All,
>
>This issue started to be real blocker for my client's application. If we
>could ask anyone from compiler sight to try to work on that it would be
>awesome and simply help with farther development those app in FlexJS. [1]
>
>I think option where we are going with "localID" is ok to me. Alex mention
>in the email that whoever will be looking into that should check how is
>handled "id" and do similar things with "localID". The changes should be
>done in MXMLClassDIrectiveProcessor, MXMLFlexJSEmitter and probably would
>be
>involved MXMLDataInterpreter in AS code.
>
>I will probably start to learn compiler things, but will be on vacation
>next
>week and this become really urgent.
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.ap
>ache.org%2Fjira%2Fbrowse%2FFLEX-35310&data=02%7C01%7C%7C0ba51e4cc695440140
>1408d4da9954a7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63637379948191
>6198&sdata=nW3No1ZzOoi%2FgcJzzt6mQ7XO5FLC5FkUOtcHwuCib0k%3D&reserved=0
>
>Thank you,
>Piotr
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.2333347.n4.nabble.com%2FFlexJS-MXML-ids-and-classNames-tp543
>61p63688.html&data=02%7C01%7C%7C0ba51e4cc6954401401408d4da9954a7%7Cfa7b1b5
>a7b34438794aed2c178decee1%7C0%7C0%7C636373799481916198&sdata=fNdhk1Gbe%2Bu
>cFwizioCJz114fRCaN%2B0PN88S1REUNzg%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames - FLEX-35310
Posted by piotrz <pi...@gmail.com>.
Hi All,
This issue started to be real blocker for my client's application. If we
could ask anyone from compiler sight to try to work on that it would be
awesome and simply help with farther development those app in FlexJS. [1]
I think option where we are going with "localID" is ok to me. Alex mention
in the email that whoever will be looking into that should check how is
handled "id" and do similar things with "localID". The changes should be
done in MXMLClassDIrectiveProcessor, MXMLFlexJSEmitter and probably would be
involved MXMLDataInterpreter in AS code.
I will probably start to learn compiler things, but will be on vacation next
week and this become really urgent.
[1] https://issues.apache.org/jira/browse/FLEX-35310
Thank you,
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p63688.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames - FLEX-35310
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Piotr,
I still don't think the compiler can tell if you will be using an id more
than once. At least not with a lot of flow analysis and even then I think
we'd miss cases.
You should be able to use the same id more than once. You might be
removing the first view and replacing it with a different view and both
might have the same id.
IMO, the only warning must be done at runtime. Feel free to create a
DuplicateIDCheckingBead that does that work. I think it would replace the
UIBase id setter with a version that calls getElementById on the proposed
id.
My 2 cents,
-Alex
On 7/17/17, 3:20 AM, "piotrz" <pi...@gmail.com> wrote:
>Hi Alex,
>
>That's a valid point and I think I'm willing to change my vote to have
>localId. Let me understand fully this. If we introduce "localId" -
>
>- We will be able to have same id in different view - Introducing that new
>field is less time consuming than doing solution which I vote for ?
>- Compiler will shot us some warning if we have duplicate "id" ?
>
>Thanks,
>Piotr
>
>
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.2333347.n4.nabble.com%2FFlexJS-MXML-ids-and-classNames-tp543
>61p63328.html&data=02%7C01%7C%7C8772b947ed204967a34408d4cd002f3c%7Cfa7b1b5
>a7b34438794aed2c178decee1%7C0%7C0%7C636358848070298436&sdata=18lcB0kmjhL1q
>64dKeWha7%2B96F%2F%2BtECazuFZ2X2F5AM%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames - FLEX-35310
Posted by piotrz <pi...@gmail.com>.
Hi Alex,
That's a valid point and I think I'm willing to change my vote to have
localId. Let me understand fully this. If we introduce "localId" -
- We will be able to have same id in different view - Introducing that new
field is less time consuming than doing solution which I vote for ?
- Compiler will shot us some warning if we have duplicate "id" ?
Thanks,
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p63328.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames - FLEX-35310
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Well, it makes no sense to me to invent some new property name that sets
the "id" of an HTMLElement. I would think we'd get a ton of questions
about it. If I"m the only one who thinks that, then I'll stop arguing
against it. I thought the consensus upthread was to add localId.
-Alex
On 7/16/17, 11:16 AM, "piotrz" <pi...@gmail.com> wrote:
>Josh,
>
>In general if I correct understand that was your idea. I think it is the
>simpler solution where we
>- Stop set up "id" to HTML id
>- Introduce new property which will set up it in html
>
>+1 for Josh's idea.
>
>Thanks,
>Piotr
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.2333347.n4.nabble.com%2FFlexJS-MXML-ids-and-classNames-tp543
>61p63315.html&data=02%7C01%7C%7C93dc53d5c28f4e49156408d4cc7970af%7Cfa7b1b5
>a7b34438794aed2c178decee1%7C0%7C0%7C636358269329946292&sdata=APogtmBEyf0%2
>BbZVWxl5H%2B%2BT65fTWXDS%2Fys9Ph3aQUmU%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames - FLEX-35310
Posted by piotrz <pi...@gmail.com>.
Josh,
In general if I correct understand that was your idea. I think it is the
simpler solution where we
- Stop set up "id" to HTML id
- Introduce new property which will set up it in html
+1 for Josh's idea.
Thanks,
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p63315.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames - FLEX-35310
Posted by Josh Tynjala <jo...@gmail.com>.
If we change the behavior of id in MXML, there needs to be a way to force
the compiler to make id behave the old way. The compiler is used for more
than just compiling FlexJS. For instance, it is used in my VSCode
extension, where it provides code intelligence for MXML with the classic
Flex SDK and the Feathers SDK. In those cases, id must create a property on
the existing class, as it always has, and it cannot be replaced by a
different property for the same purpose.
- Josh
On Jul 15, 2017 2:25 AM, "piotrz" <pi...@gmail.com> wrote:
> Hi All,
>
> I think one of the biggest fish which we should fry is currently issue with
> duplication id. There need to be changes in compiler which seems to be for
> someone who really know the code. I would like to get back to the
> discussion
> and set up here some final decision. Let's have small vote cause we gather
> enough ideas.
>
> If I miss something or someone would like add more thoughts let it be, but
> let's move with this forward.
>
> Proposition 1: (Alex): Have "id" and "mxmlID". [1]
> Proposition 2: (Yishay): Have "localId" [2] - similar to [1]
> Proposition 3: (Alex): Additional idea where "localId" ("mxmlID") is
> actually not set on an object, working like "includeIn" [3]
> Proposition 4: (Josh): "id" will no longer set "id" in HTML, introduce new
> property called "htmlID" or "globalID" [4]
> Proposition 5: (Chris) [5]: Internal "id" based on parent components
>
> [1] https://goo.gl/CBkST5
> [2] https://goo.gl/C43Y4U
> [3] https://goo.gl/2aFghn
> [4] https://goo.gl/VTd25g
> [5] https://goo.gl/8rDMPU
>
> Thanks,
> Piotr
>
>
>
> -----
> Apache Flex PMC
> piotrzarzycki21@gmail.com
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-
> classNames-tp54361p63276.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
FlexJS MXML ids and classNames - FLEX-35310
Posted by piotrz <pi...@gmail.com>.
Hi All,
I think one of the biggest fish which we should fry is currently issue with
duplication id. There need to be changes in compiler which seems to be for
someone who really know the code. I would like to get back to the discussion
and set up here some final decision. Let's have small vote cause we gather
enough ideas.
If I miss something or someone would like add more thoughts let it be, but
let's move with this forward.
Proposition 1: (Alex): Have "id" and "mxmlID". [1]
Proposition 2: (Yishay): Have "localId" [2] - similar to [1]
Proposition 3: (Alex): Additional idea where "localId" ("mxmlID") is
actually not set on an object, working like "includeIn" [3]
Proposition 4: (Josh): "id" will no longer set "id" in HTML, introduce new
property called "htmlID" or "globalID" [4]
Proposition 5: (Chris) [5]: Internal "id" based on parent components
[1] https://goo.gl/CBkST5
[2] https://goo.gl/C43Y4U
[3] https://goo.gl/2aFghn
[4] https://goo.gl/VTd25g
[5] https://goo.gl/8rDMPU
Thanks,
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p63276.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com>.
On 8/7/16, 4:09 AM, "Harbs" <ha...@gmail.com> 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
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
Alex,
You mean that I will not be able call property in AS3 like this ?
<SomeBaseClass>
<SomeClass mxmlID="bar" someProperty="baz" />
</SomeBaseClass>
<fx:Script></fx:Script>
I'm not following where the problem is.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61722.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by Christofer Dutz <ch...@c-ware.de>.
I never said that I wanted to prohibit styling by id … just that you would probably have to use the full id (with the parent path) instead of the local one.
Chris
Am 23.05.17, 20:45 schrieb "piotrz" <pi...@gmail.com>:
Chris,
Thank you for explanation!
The idea where we abandon or even do not allow styling css through the "id"
is something which I would definitely not give +1. Styling by "id" it's
something so common in HTML world - doesn't matter whether it's bad, people
are doing like that, framework are doing like that etc. I'm not sure why we
are trying to complicate so much everything. The only thing which we need
for sure is some "localId"/"mxmlId" or something like that which allow us
use many id with same value in multiple views.
Maybe there are scenario where need to be also done some automatic
generation for main "id" when we are using "localId"/"mxmlId" but yeah, even
without that we can live better than currently is. Let's have simple option
to see how it's working - than go farther.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61803.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
Chris,
Thank you for explanation!
The idea where we abandon or even do not allow styling css through the "id"
is something which I would definitely not give +1. Styling by "id" it's
something so common in HTML world - doesn't matter whether it's bad, people
are doing like that, framework are doing like that etc. I'm not sure why we
are trying to complicate so much everything. The only thing which we need
for sure is some "localId"/"mxmlId" or something like that which allow us
use many id with same value in multiple views.
Maybe there are scenario where need to be also done some automatic
generation for main "id" when we are using "localId"/"mxmlId" but yeah, even
without that we can live better than currently is. Let's have simple option
to see how it's working - than go farther.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61803.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by Christofer Dutz <ch...@c-ware.de>.
Well in that case wherever I run into something like this, the solution is to simply append the row id as an intermediate.
containerId:rowId:localItemRendererId
Chris
Am 23.05.17, 16:34 schrieb "Alex Harui" <ah...@adobe.com.INVALID>:
On 5/23/17, 12:28 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>Hi Piotr,
>
>Well in the old Flex world there was no global id like concept. There
>were only local ids, only in rare cases we needed to access stuff “above”
>and that’s what the parent was used for. So I guess that in general the
>same should apply for new MXML components. The only difference is that in
>Flex we didn’t need the id’s to be globally unique, in JS they however
>need to be unique. What I’m proposing, is to continue using only local
>ids, but have the compiler or the framework use the “id” attribute in
>MXML and to translate that into an “effective-global-id” by appending the
>parents “effective-global-id” with “:{local-id}” generating a new global
>id. This would eliminate a lot of possible problems, but also it would
>probably break the option to style elements with CSS based on their id.
>But I think that’s bad practice anyway, I usually use style classes for
>that. If you want to continue to use ids, you would simply have to
>replace the “lala” CSS id selector with
>“myapp:someintermediate:another:lala” and all should continue to work.
>Don’t know if there are any other drawbacks.
Maybe I don't understand your plan, but for an MXML item renderer where an
"id" is used in the MXML, there could be more than one instance of it with
the exact same parent List.
-Alex
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 5/23/17, 12:28 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:
>Hi Piotr,
>
>Well in the old Flex world there was no global id like concept. There
>were only local ids, only in rare cases we needed to access stuff “above”
>and that’s what the parent was used for. So I guess that in general the
>same should apply for new MXML components. The only difference is that in
>Flex we didn’t need the id’s to be globally unique, in JS they however
>need to be unique. What I’m proposing, is to continue using only local
>ids, but have the compiler or the framework use the “id” attribute in
>MXML and to translate that into an “effective-global-id” by appending the
>parents “effective-global-id” with “:{local-id}” generating a new global
>id. This would eliminate a lot of possible problems, but also it would
>probably break the option to style elements with CSS based on their id.
>But I think that’s bad practice anyway, I usually use style classes for
>that. If you want to continue to use ids, you would simply have to
>replace the “lala” CSS id selector with
>“myapp:someintermediate:another:lala” and all should continue to work.
>Don’t know if there are any other drawbacks.
Maybe I don't understand your plan, but for an MXML item renderer where an
"id" is used in the MXML, there could be more than one instance of it with
the exact same parent List.
-Alex
Re: FlexJS MXML ids and classNames
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Piotr,
Well in the old Flex world there was no global id like concept. There were only local ids, only in rare cases we needed to access stuff “above” and that’s what the parent was used for. So I guess that in general the same should apply for new MXML components. The only difference is that in Flex we didn’t need the id’s to be globally unique, in JS they however need to be unique. What I’m proposing, is to continue using only local ids, but have the compiler or the framework use the “id” attribute in MXML and to translate that into an “effective-global-id” by appending the parents “effective-global-id” with “:{local-id}” generating a new global id. This would eliminate a lot of possible problems, but also it would probably break the option to style elements with CSS based on their id. But I think that’s bad practice anyway, I usually use style classes for that. If you want to continue to use ids, you would simply have to replace the “lala” CSS id selector with “myapp:someintermediate:another:lala” and all should continue to work. Don’t know if there are any other drawbacks.
Chris
Am 22.05.17, 22:50 schrieb "piotrz" <pi...@gmail.com>:
Chris,
I think accessing "parent" and having pair of properties which prevents us
from being duplicated when your are using same value of those properties in
other views is something else.
Maybe I'm not fully following your idea. Are saying that "localId" should be
translated to HTML? - that's what proposition is. What is the second part
with parent ? I think in this discussion we don't care about parent, but
maybe you have some other view.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61749.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
Chris,
I think accessing "parent" and having pair of properties which prevents us
from being duplicated when your are using same value of those properties in
other views is something else.
Maybe I'm not fully following your idea. Are saying that "localId" should be
translated to HTML? - that's what proposition is. What is the second part
with parent ? I think in this discussion we don't care about parent, but
maybe you have some other view.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61749.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
Alex,
Exactly that what is happened. The third party library MDL and some other
one complains about that in some project - That's why I've put back this
topic to the discussion.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61804.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi guys,
In Flex we only had local id's, correct? If we wanted to access something somewhere else, we usually used "parent". Shouldn't this be possible in flexjs to? Sort of, only use local ids and have these translated to html id's by the compiler, by adding the local is to the parents id. I think with this we had the same concept as flex had and it would prevent a lot of problems. A special way to force global id wild make other concepts possible.
Chris
Von meinem Samsung Galaxy Smartphone gesendet.
-------- Ursprüngliche Nachricht --------
Von: piotrz <pi...@gmail.com>
Datum: 22.05.17 20:51 (GMT+01:00)
An: dev@flex.apache.org
Betreff: Re: FlexJS MXML ids and classNames
Hi Alex,
I was going to expand my thoughts on same concerns what Chris mention. If we
introduce "localId" which will be responsible for identifying components in
MXML we need to also generate "id" - based on those "localId" - cause in
many cases "id" will be required in HTML once we set "localId".
Some external library may require those "id".
Summarize a bit we have so far following ideas:
1) Introduce "localId" or "mxmlId" as entity which is not translated to HTML
2) Introduce "globalId" which will be translated to HTML, but "id" not
necessary (Josh Am I understand you right ?) - But that would break existing
applications, cause we have right now "id" translation to HTML.
Related to introduced new property:
1) Have the compiler check that HTML ids are not used more than once. (Harbs
- Globally ?, If id is used more than once in many views ?)
2) Ability set HTML ids (Harbs I need a bit more elaboration on this, cause
I do not fully understand)
3) "id" should be generated based on "localId" or make generation based on
Chris's suggestions (Piotr, Chris)
If I miss something or didn't understand enough please correct me.
Thanks for a good discussion on that!
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61745.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
+1 to Josh's proposition.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61747.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 5/22/17, 10:34 PM, "piotrz" <pi...@gmail.com> wrote:
>Hi Alex,
>
>You convinced me more to do not touch "id", and if we won't touch it and
>introduce "localId" not translatable to HTML we will achieve those what we
>want. However in order to resolve problems with third party library "id"
>still need to be generated somehow if we setup "localId".
I'm not sure I understand your last point. If the third-party library is
expecting an "id", you should set "id" and not "localID".
Thanks,
-Alex
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
Hi Alex,
You convinced me more to do not touch "id", and if we won't touch it and
introduce "localId" not translatable to HTML we will achieve those what we
want. However in order to resolve problems with third party library "id"
still need to be generated somehow if we setup "localId". That's my
understanding.
If it hard to teach compiler how to detect whether id is duplicated - that's
fine, for me it is optionable.
In my opinion it should be first thing to do right after release. Definitely
on some feature branch.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61754.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by Josh Tynjala <jo...@gmail.com>.
Agreed. This is something that should definitely be in the release notes.
- Josh
On Mon, May 22, 2017 at 3:44 PM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > This change would indeed break existing FlexJS applications that used the
> > HTML id in some way (like in CSS). However, we're pre-1.0, so breaking
> > changes are still to be expected while we smooth things over.
>
> If we do break something we need to document how to work around it. Thee’s
> project out there that are using FlexJS and even breaking change we make
> will cause those projects to work out some fix and/or time to fix it.
>
> Thanks,
> Justin
Re: FlexJS MXML ids and classNames
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> This change would indeed break existing FlexJS applications that used the
> HTML id in some way (like in CSS). However, we're pre-1.0, so breaking
> changes are still to be expected while we smooth things over.
If we do break something we need to document how to work around it. Thee’s project out there that are using FlexJS and even breaking change we make will cause those projects to work out some fix and/or time to fix it.
Thanks,
Justin
Re: FlexJS MXML ids and classNames
Posted by Josh Tynjala <jo...@gmail.com>.
Yes, browsers will allow multiple ids without error. I know for sure that
document.getElementById() will simply return the first element with the id
that it finds in the DOM. I'm not as sure about how duplicate ids in the
DOM are treated by CSS, but I wouldn't be surprised if you were right and
they'll all get the same styles.
- Josh
On Tue, May 23, 2017 at 7:45 AM, Alex Harui <ah...@adobe.com.invalid>
wrote:
>
>
> On 5/23/17, 7:32 AM, "Josh Tynjala" <jo...@gmail.com> wrote:
>
> >I didn't consider that ids were supported in classic Flex SDK CSS. In that
> >case, I guess it really was global then.
>
> I guess you can think of that as global, but really, there isn't any
> restriction in regular Flex or FlexJS on having one and only one id. You
> could have many instances with the same ID and the CSS ID selector would
> work for each one. I haven't tried this in the browser for JS output, but
> I would guess it would work there as well. I think the browsers are
> forgiving despite what the spec says. AIUI, the browser didn't complain
> when Piotr had duplicate ids. It was third-party library code that had an
> expectation.
>
> Of course, I could be wrong...
> -Alex
>
>
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 5/23/17, 7:32 AM, "Josh Tynjala" <jo...@gmail.com> wrote:
>I didn't consider that ids were supported in classic Flex SDK CSS. In that
>case, I guess it really was global then.
I guess you can think of that as global, but really, there isn't any
restriction in regular Flex or FlexJS on having one and only one id. You
could have many instances with the same ID and the CSS ID selector would
work for each one. I haven't tried this in the browser for JS output, but
I would guess it would work there as well. I think the browsers are
forgiving despite what the spec says. AIUI, the browser didn't complain
when Piotr had duplicate ids. It was third-party library code that had an
expectation.
Of course, I could be wrong...
-Alex
Re: FlexJS MXML ids and classNames
Posted by Josh Tynjala <jo...@gmail.com>.
I didn't consider that ids were supported in classic Flex SDK CSS. In that
case, I guess it really was global then. With that in mind, I guess I'm
okay with adding the option to use localID instead of id when you want a
member variable but not an HTML id.
I suppose this change will require compiler changes. If we wanted to avoid
that, for any reason, we might consider an alternative of adding a boolean
property to UIBase (or whatever) that tells the component not to set the
HTML id. Maybe something like this:
<MyComp id="something" noGlobalID="true"/>
I think I'd prefer localID over this option, though. I just thought I'd
mention it, since it came to mind.
- Josh
On Mon, May 22, 2017 at 8:56 PM, Alex Harui <ah...@adobe.com.invalid>
wrote:
> Hmm. I'm just now catching up on this thread. Are we sure this
> 'globalID' proposal is the right one? What happened to Piotr's concern
> that 3rd party libraries might recommend setting the 'id' property. Or
> similarly, that some CSS theme is expecting you to set 'id'. I'd be
> worried we'd be constantly having to tell folks to use the 'globalID'
> property.
>
> There might be other options: Maybe there is some directive that you use
> in an MXML file that doesn't result in code that sets the id property on
> the object. How often do folks have more than one instance of an MXML
> class in the DOM at one time? I think mainly in item renderers?
>
> I have no idea how to execute on the compiler detecting multiple uses of
> id. I don't think the compiler knows that a class in a SWC was generated
> from MXML and sets the id property. Or that someone set id from an
> ActionScript class. I think someone could write a bead that watches for
> multiple setting of the 'id' property.
>
> I'm not sure the "backward compatibility" of the 'id' property should win
> out over the mapping of 'id' to the actual 'id' in the DOM. Regular Flex
> supported 'id' selectors. How would that work in the 'globalID' proposal?
> If 'id' doesn't get set then someone's old code that used an 'id'
> selector will not work. They will have to modify their code to use
> globalID instead.
>
> So, I think the factors are:
> 1) There are existing CSS files for Flex that use ID selectors.
> 2) There are existing CSS files for JS libraries and themes that use ID
> selectors
> 3) The MXML item renderers might use IDs resulting in more than one
> instance with the same ID in the DOM, and also multiple pairs of IDs if
> you make up IDs based on parent + child.
>
> Anyway, are folks thinking we need to do something about this for this
> release? I'd rather not delay the release for this only to find out we
> missed out on some ramification.
>
> Thoughts?
> -Alex
>
> On 5/22/17, 4:47 PM, "Harbs" <ha...@gmail.com> wrote:
>
> >+1
> >
> >> On May 22, 2017, at 3:13 PM, Josh Tynjala <jo...@gmail.com>
> wrote:
> >>
> >> Yes, with my proposal, globalID would be translated to HTML. With id, it
> >> would go back to the classic behavior of adding a member variable to the
> >> class only and not being translated to a global HTML id.
> >>
> >> This change would indeed break existing FlexJS applications that used
> >>the
> >> HTML id in some way (like in CSS). However, we're pre-1.0, so breaking
> >> changes are still to be expected while we smooth things over. I would
> >> rather fix id to put it back to the original behavior of affecting the
> >> current class only than add a workaround like localID/mxmlID for the
> >>fact
> >> that id was overloaded to mean something at the global-level too.
> >>
> >> - Josh
> >>
> >>
> >> On Mon, May 22, 2017 at 11:37 AM, piotrz <pi...@gmail.com>
> >>wrote:
> >>
> >>> Hi Alex,
> >>>
> >>> I was going to expand my thoughts on same concerns what Chris mention.
> >>>If
> >>> we
> >>> introduce "localId" which will be responsible for identifying
> >>>components in
> >>> MXML we need to also generate "id" - based on those "localId" - cause
> >>>in
> >>> many cases "id" will be required in HTML once we set "localId".
> >>>
> >>> Some external library may require those "id".
> >>>
> >>> Summarize a bit we have so far following ideas:
> >>> 1) Introduce "localId" or "mxmlId" as entity which is not translated to
> >>> HTML
> >>> 2) Introduce "globalId" which will be translated to HTML, but "id" not
> >>> necessary (Josh Am I understand you right ?) - But that would break
> >>> existing
> >>> applications, cause we have right now "id" translation to HTML.
> >>>
> >>> Related to introduced new property:
> >>> 1) Have the compiler check that HTML ids are not used more than once.
> >>> (Harbs
> >>> - Globally ?, If id is used more than once in many views ?)
> >>> 2) Ability set HTML ids (Harbs I need a bit more elaboration on this,
> >>> cause
> >>> I do not fully understand)
> >>> 3) "id" should be generated based on "localId" or make generation
> >>>based on
> >>> Chris's suggestions (Piotr, Chris)
> >>>
> >>> If I miss something or didn't understand enough please correct me.
> >>>
> >>> Thanks for a good discussion on that!
> >>> Piotr
> >>>
> >>>
> >>>
> >>>
> >>> -----
> >>> Apache Flex PMC
> >>> piotrzarzycki21@gmail.com
> >>> --
> >>> View this message in context: http://apache-flex-
> >>> development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-
> >>> classNames-tp54361p61745.html
> >>> Sent from the Apache Flex Development mailing list archive at
> >>>Nabble.com.
> >>>
> >
>
>
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hmm. I'm just now catching up on this thread. Are we sure this
'globalID' proposal is the right one? What happened to Piotr's concern
that 3rd party libraries might recommend setting the 'id' property. Or
similarly, that some CSS theme is expecting you to set 'id'. I'd be
worried we'd be constantly having to tell folks to use the 'globalID'
property.
There might be other options: Maybe there is some directive that you use
in an MXML file that doesn't result in code that sets the id property on
the object. How often do folks have more than one instance of an MXML
class in the DOM at one time? I think mainly in item renderers?
I have no idea how to execute on the compiler detecting multiple uses of
id. I don't think the compiler knows that a class in a SWC was generated
from MXML and sets the id property. Or that someone set id from an
ActionScript class. I think someone could write a bead that watches for
multiple setting of the 'id' property.
I'm not sure the "backward compatibility" of the 'id' property should win
out over the mapping of 'id' to the actual 'id' in the DOM. Regular Flex
supported 'id' selectors. How would that work in the 'globalID' proposal?
If 'id' doesn't get set then someone's old code that used an 'id'
selector will not work. They will have to modify their code to use
globalID instead.
So, I think the factors are:
1) There are existing CSS files for Flex that use ID selectors.
2) There are existing CSS files for JS libraries and themes that use ID
selectors
3) The MXML item renderers might use IDs resulting in more than one
instance with the same ID in the DOM, and also multiple pairs of IDs if
you make up IDs based on parent + child.
Anyway, are folks thinking we need to do something about this for this
release? I'd rather not delay the release for this only to find out we
missed out on some ramification.
Thoughts?
-Alex
On 5/22/17, 4:47 PM, "Harbs" <ha...@gmail.com> wrote:
>+1
>
>> On May 22, 2017, at 3:13 PM, Josh Tynjala <jo...@gmail.com> wrote:
>>
>> Yes, with my proposal, globalID would be translated to HTML. With id, it
>> would go back to the classic behavior of adding a member variable to the
>> class only and not being translated to a global HTML id.
>>
>> This change would indeed break existing FlexJS applications that used
>>the
>> HTML id in some way (like in CSS). However, we're pre-1.0, so breaking
>> changes are still to be expected while we smooth things over. I would
>> rather fix id to put it back to the original behavior of affecting the
>> current class only than add a workaround like localID/mxmlID for the
>>fact
>> that id was overloaded to mean something at the global-level too.
>>
>> - Josh
>>
>>
>> On Mon, May 22, 2017 at 11:37 AM, piotrz <pi...@gmail.com>
>>wrote:
>>
>>> Hi Alex,
>>>
>>> I was going to expand my thoughts on same concerns what Chris mention.
>>>If
>>> we
>>> introduce "localId" which will be responsible for identifying
>>>components in
>>> MXML we need to also generate "id" - based on those "localId" - cause
>>>in
>>> many cases "id" will be required in HTML once we set "localId".
>>>
>>> Some external library may require those "id".
>>>
>>> Summarize a bit we have so far following ideas:
>>> 1) Introduce "localId" or "mxmlId" as entity which is not translated to
>>> HTML
>>> 2) Introduce "globalId" which will be translated to HTML, but "id" not
>>> necessary (Josh Am I understand you right ?) - But that would break
>>> existing
>>> applications, cause we have right now "id" translation to HTML.
>>>
>>> Related to introduced new property:
>>> 1) Have the compiler check that HTML ids are not used more than once.
>>> (Harbs
>>> - Globally ?, If id is used more than once in many views ?)
>>> 2) Ability set HTML ids (Harbs I need a bit more elaboration on this,
>>> cause
>>> I do not fully understand)
>>> 3) "id" should be generated based on "localId" or make generation
>>>based on
>>> Chris's suggestions (Piotr, Chris)
>>>
>>> If I miss something or didn't understand enough please correct me.
>>>
>>> Thanks for a good discussion on that!
>>> Piotr
>>>
>>>
>>>
>>>
>>> -----
>>> Apache Flex PMC
>>> piotrzarzycki21@gmail.com
>>> --
>>> View this message in context: http://apache-flex-
>>> development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-
>>> classNames-tp54361p61745.html
>>> Sent from the Apache Flex Development mailing list archive at
>>>Nabble.com.
>>>
>
Re: FlexJS MXML ids and classNames
Posted by Harbs <ha...@gmail.com>.
+1
> On May 22, 2017, at 3:13 PM, Josh Tynjala <jo...@gmail.com> wrote:
>
> Yes, with my proposal, globalID would be translated to HTML. With id, it
> would go back to the classic behavior of adding a member variable to the
> class only and not being translated to a global HTML id.
>
> This change would indeed break existing FlexJS applications that used the
> HTML id in some way (like in CSS). However, we're pre-1.0, so breaking
> changes are still to be expected while we smooth things over. I would
> rather fix id to put it back to the original behavior of affecting the
> current class only than add a workaround like localID/mxmlID for the fact
> that id was overloaded to mean something at the global-level too.
>
> - Josh
>
>
> On Mon, May 22, 2017 at 11:37 AM, piotrz <pi...@gmail.com> wrote:
>
>> Hi Alex,
>>
>> I was going to expand my thoughts on same concerns what Chris mention. If
>> we
>> introduce "localId" which will be responsible for identifying components in
>> MXML we need to also generate "id" - based on those "localId" - cause in
>> many cases "id" will be required in HTML once we set "localId".
>>
>> Some external library may require those "id".
>>
>> Summarize a bit we have so far following ideas:
>> 1) Introduce "localId" or "mxmlId" as entity which is not translated to
>> HTML
>> 2) Introduce "globalId" which will be translated to HTML, but "id" not
>> necessary (Josh Am I understand you right ?) - But that would break
>> existing
>> applications, cause we have right now "id" translation to HTML.
>>
>> Related to introduced new property:
>> 1) Have the compiler check that HTML ids are not used more than once.
>> (Harbs
>> - Globally ?, If id is used more than once in many views ?)
>> 2) Ability set HTML ids (Harbs I need a bit more elaboration on this,
>> cause
>> I do not fully understand)
>> 3) "id" should be generated based on "localId" or make generation based on
>> Chris's suggestions (Piotr, Chris)
>>
>> If I miss something or didn't understand enough please correct me.
>>
>> Thanks for a good discussion on that!
>> Piotr
>>
>>
>>
>>
>> -----
>> Apache Flex PMC
>> piotrzarzycki21@gmail.com
>> --
>> View this message in context: http://apache-flex-
>> development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-
>> classNames-tp54361p61745.html
>> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>>
Re: FlexJS MXML ids and classNames
Posted by Josh Tynjala <jo...@gmail.com>.
Yes, with my proposal, globalID would be translated to HTML. With id, it
would go back to the classic behavior of adding a member variable to the
class only and not being translated to a global HTML id.
This change would indeed break existing FlexJS applications that used the
HTML id in some way (like in CSS). However, we're pre-1.0, so breaking
changes are still to be expected while we smooth things over. I would
rather fix id to put it back to the original behavior of affecting the
current class only than add a workaround like localID/mxmlID for the fact
that id was overloaded to mean something at the global-level too.
- Josh
On Mon, May 22, 2017 at 11:37 AM, piotrz <pi...@gmail.com> wrote:
> Hi Alex,
>
> I was going to expand my thoughts on same concerns what Chris mention. If
> we
> introduce "localId" which will be responsible for identifying components in
> MXML we need to also generate "id" - based on those "localId" - cause in
> many cases "id" will be required in HTML once we set "localId".
>
> Some external library may require those "id".
>
> Summarize a bit we have so far following ideas:
> 1) Introduce "localId" or "mxmlId" as entity which is not translated to
> HTML
> 2) Introduce "globalId" which will be translated to HTML, but "id" not
> necessary (Josh Am I understand you right ?) - But that would break
> existing
> applications, cause we have right now "id" translation to HTML.
>
> Related to introduced new property:
> 1) Have the compiler check that HTML ids are not used more than once.
> (Harbs
> - Globally ?, If id is used more than once in many views ?)
> 2) Ability set HTML ids (Harbs I need a bit more elaboration on this,
> cause
> I do not fully understand)
> 3) "id" should be generated based on "localId" or make generation based on
> Chris's suggestions (Piotr, Chris)
>
> If I miss something or didn't understand enough please correct me.
>
> Thanks for a good discussion on that!
> Piotr
>
>
>
>
> -----
> Apache Flex PMC
> piotrzarzycki21@gmail.com
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-
> classNames-tp54361p61745.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
Hi Alex,
I was going to expand my thoughts on same concerns what Chris mention. If we
introduce "localId" which will be responsible for identifying components in
MXML we need to also generate "id" - based on those "localId" - cause in
many cases "id" will be required in HTML once we set "localId".
Some external library may require those "id".
Summarize a bit we have so far following ideas:
1) Introduce "localId" or "mxmlId" as entity which is not translated to HTML
2) Introduce "globalId" which will be translated to HTML, but "id" not
necessary (Josh Am I understand you right ?) - But that would break existing
applications, cause we have right now "id" translation to HTML.
Related to introduced new property:
1) Have the compiler check that HTML ids are not used more than once. (Harbs
- Globally ?, If id is used more than once in many views ?)
2) Ability set HTML ids (Harbs I need a bit more elaboration on this, cause
I do not fully understand)
3) "id" should be generated based on "localId" or make generation based on
Chris's suggestions (Piotr, Chris)
If I miss something or didn't understand enough please correct me.
Thanks for a good discussion on that!
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61745.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by Christofer Dutz <ch...@c-ware.de>.
Just replying to the last mail of the thread.
I think a lot of other JS frameworks have the same set of problems. I think a solution most of them use is to create internal ids based upon the id and the id of the parent component.
In JSF for example they create these ids by this: “{parentId}:{id}” … internally id lookups have to be adjusted, so if in a component a lookup for “foo” is done, the compiler translates this to “{parentId}:foo”. This should also make it quite easy to implement test-automation.
But I have no idea what downside this has (except for making the ids longer)
Chris
Am 21.05.17, 17:46 schrieb "piotrz" <pi...@gmail.com>:
More thinking about that we need for sure one property or pseudo property
which will resolve issue with "id" duplication, the other one for me is
something optional.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61729.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
More thinking about that we need for sure one property or pseudo property
which will resolve issue with "id" duplication, the other one for me is
something optional.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61729.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
Yep I agree with Harbs and Josh as for not touch at all id and maybe
introduce another two.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61726.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by Harbs <ha...@gmail.com>.
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 <jo...@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" <jo...@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" <ah...@adobe.com.invalid> wrote:
>
>
>
> On 5/21/17, 1:38 AM, "yishayw" <yi...@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
Re: FlexJS MXML ids and classNames
Posted by Josh Tynjala <jo...@gmail.com>.
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" <jo...@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" <ah...@adobe.com.invalid> wrote:
On 5/21/17, 1:38 AM, "yishayw" <yi...@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
Re: FlexJS MXML ids and classNames
Posted by Josh Tynjala <jo...@gmail.com>.
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" <ah...@adobe.com.invalid> wrote:
On 5/21/17, 1:38 AM, "yishayw" <yi...@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
Re: FlexJS MXML ids and classNames
Posted by Harbs <ha...@gmail.com>.
I don’t really what we call this, but I think the following is important:
I would like an option for the following:
1. Ability to set an id in mxml-only
2. Ability set HTML ids
3. Have the compiler check that HTML ids are not used more than once.
> On May 21, 2017, at 10:58 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
>
>
> On 5/21/17, 1:38 AM, "yishayw" <yi...@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
>
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 5/21/17, 1:38 AM, "yishayw" <yi...@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
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
Hi Yishay,
From my perspective it is important to have such property. +1 for name
localID.
Thanks,
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61712.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by yishayw <yi...@hotmail.com>.
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'.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61710.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
Hi Justin,
I just checked and yes I'm running into exactly same issue.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61709.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 5/20/17, 3:17 PM, "Justin Mclean" <ju...@classsoftware.com> 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
Re: FlexJS MXML ids and classNames
Posted by Justin Mclean <ju...@classsoftware.com>.
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
Re: FlexJS MXML ids and classNames
Posted by piotrz <pi...@gmail.com>.
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
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-tp54361p61706.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS MXML ids and classNames
Posted by Harbs <ha...@gmail.com>.
>
> 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.
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com>.
On 8/8/16, 10:24 PM, "Harbs" <ha...@gmail.com> 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
Re: FlexJS MXML ids and classNames
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com> wrote:
>
>
> On 8/8/16, 8:29 AM, "Harbs" <ha...@gmail.com> 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
>
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com>.
On 8/8/16, 8:29 AM, "Harbs" <ha...@gmail.com> 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
Re: FlexJS MXML ids and classNames
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com> wrote:
>
>
> On 8/8/16, 7:54 AM, "Harbs" <ha...@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 <jo...@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 <ha...@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 <ah...@adobe.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 8/7/16, 2:08 PM, "Harbs" <ha...@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 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
>>>>>
>>>>
>>>>
>>
>
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com>.
On 8/8/16, 7:54 AM, "Harbs" <ha...@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 <jo...@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 <ha...@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 <ah...@adobe.com> wrote:
>>>
>>>>
>>>>
>>>> On 8/7/16, 2:08 PM, "Harbs" <ha...@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 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
>>>>
>>>
>>>
>
Re: FlexJS MXML ids and classNames
Posted by Harbs <ha...@gmail.com>.
Agreed. That’s why I’m suggestion we using “elementID” instead.
On Aug 8, 2016, at 5:46 PM, Josh Tynjala <jo...@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 <ha...@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 <ah...@adobe.com> wrote:
>>
>>>
>>>
>>> On 8/7/16, 2:08 PM, "Harbs" <ha...@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 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
>>>
>>
>>
Re: FlexJS MXML ids and classNames
Posted by Josh Tynjala <jo...@gmail.com>.
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 <ha...@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 <ah...@adobe.com> wrote:
>
> >
> >
> > On 8/7/16, 2:08 PM, "Harbs" <ha...@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 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
> >
>
>
Re: FlexJS MXML ids and classNames
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com> wrote:
>
>
> On 8/7/16, 2:08 PM, "Harbs" <ha...@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 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
>
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com>.
On 8/7/16, 2:08 PM, "Harbs" <ha...@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 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
Re: FlexJS MXML ids and classNames
Posted by Harbs <ha...@gmail.com>.
On Aug 7, 2016, at 11:47 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 8/7/16, 9:46 AM, "Harbs" <ha...@gmail.com> 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.
Re: FlexJS MXML ids and classNames
Posted by Alex Harui <ah...@adobe.com>.
On 8/7/16, 9:46 AM, "Harbs" <ha...@gmail.com> 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
Re: FlexJS MXML ids and classNames
Posted by Harbs <ha...@gmail.com>.
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 <an...@gmail.com> wrote:
> On Sun, Aug 7, 2016 at 7:09 AM, Harbs <ha...@gmail.com> 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.
Re: FlexJS MXML ids and classNames
Posted by Andy Dufilie <an...@gmail.com>.
On Sun, Aug 7, 2016 at 7:09 AM, Harbs <ha...@gmail.com> 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.