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" <piotrzarzyck...@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
> piotrzarzyck...@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.
>
