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