royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Dove <>
Subject Revisiting the old debate: 'localId vs. id'
Date Fri, 02 Nov 2018 07:31:33 GMT
In collaboration with Carlos, I worked on a compiler fix for some issues
identified with localId in the javascript output. I pushed that a short
while ago. This fixes
-binding into the localId (in my local test cases) and
-some occasional issues with referencing the instance from within script
blocks in release (minified) code.
Or at least, it does so for the cases I have been testing. If anyone else
sees remaining issues with this feature that need more attention, please
let me know.

Now on to the 'subject' :
As part of 'getting familiar' with this I went back to read old threads
about 'id v.s localId'.
I *think* these [1] [2] were the main ones, but maybe I missed some other

After reading these, I wondered if anyone had changed their views about the
implementation as it is, after having used it for a while.

It may be too late to change things, but here are my quick thoughts about
-My understanding is that best practice is to avoid multiple identical ids
in the browser, irrespective of whether the browser is forgiving of that or
not. If so, it might be good to have at least an option to set the default
implementation to support 'best practice' (DOM ids 'off' by default, 'on'
explicitly, to avoid 'duplicate ids by accident'). Maybe some sort of
import wizard for a legacy flex project could do something like this in an
IDE by default though. But it could be a compiler config thing too perhaps.

-I can't think of a scenario where I would want to set both id and localId
at the same time or what doing so would mean. Either you want to set the
DOM id or you don't, in which case missing id and defined localId is more
like a boolean for not setting DOM id (the implementation is not, but to me
it seems that it could -maybe should- be). Maybe I am missing something

-'id' is the basis for code completion/intelligence in legacy IDEs. Using
'localId' means this does not work in the legacy IDEs and newer IDEs need
to add custom support for it. Anything that keeps 'id' as the primary local
identifier seems like the best way to get more life out of legacy IDEs.

So to me, the simplest option seems to be more along the lines of

<Instance id="myLocalOnlyId" localId="true" />
<Instance id="myLegacyId" localId="false" />

Semantically it is probably better as 'localIdOnly' for the boolean
setting, but 'localId' is shorter (which is perhaps better).

In this case, you get more mileage from older IDEs, and a simpler
implementation for updating IDEs to handle the extra mxml-only boolean
setting. In simple terms everything else works the same so the IDEs still
work for code intelligence.

An unspecified 'localId' boolean in mxml would currently be the same as
false, but could possibly have a global configuration default - not sure
about that, but maybe it could be useful.

If there is an issue with styling on the swf side with valid multiple ids
vs. html, then I think the swf side could perhaps be outlawed in favour of
best practice for html. Too much? :)

Anyhow, I am just raising this now in case anyone else has changed their
thinking after using it as-is for a while, and before it gets too late to
consider changing it (if it is not already too late).
If there is some consensus to change this, I am happy to work on it.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message