Hi Piotr, Thanks for your interest in this. Just to be clear, I don't want to claim that this is 'my idea' - it's more a re-visit of things that have been discussed before, and is probably very similar to some options that were decided against previously. I just wondered if anyone had changed their mind about this. I'm only raising it after some initial use of localId and just my using reaction to that experience (possibly heavily influenced by the red messages I see in Intellij).
At the moment we have <instance id="setDOMid" /> <instance localId="doNotSetDOMId" /> These seem to work well, but the second one is not nice in my IDE, compared to support for the first one. <instance id="regularId" localId="localId" /> This probably should be an error for the current implementation, as Harbs has pointed out. But at the moment it is possible and 'id' wins. What I am suggesting is that we reconsider to have only one 'id' and a second boolean flag to 'switch' it to localOnly or not. This flag could be 'localId' or 'localIdOnly', whatever seems best - I will use 'localIdOnly' below to differentiate from the above. <Instance id="myLocalOnlyId" localIdOnly="true" /> <Instance id="myLegacyId" localIdOnly ="false" /> <Instance id="myId" /> By default 'localIdOnly' would be false when it is not specified, so the same behaviour as it is now - the 3rd case above. But I think it might be helpful to have the option to have a global config for this so you could do a global default as a compiler setting to set it to true by default - e.g. like 'ignore coercion' is set up iirc. This might suit some people who prefer to 'start with things off and switch them on only if needed'. localIdOnly in the examples above is a compile time mxml-only tag setting and is not propagated to the instantiated components, so it is not a real value assignment to the instance and does not exist as a property on the instances. What this could mean: All IDEs still see the id as 'normal' legacy use - for code completion, bindings, script block references etc. The new 'unknown' localIdOnly boolean attribute is the only thing that IDEs would need to special-case, which I think should be easier than the localId string variation (I assume). On Fri, Nov 2, 2018 at 10:01 PM Piotr Zarzycki <piotrzarzyck...@gmail.com> wrote: > Hi Greg, > > I'm really happy that you are helping Carlos with that! He may move forward > much faster. I just have question to following: > > "-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." > > Does your idea is saying that if I have some Flex app or even write some on > my own setting that option to ON - change the way how things are > outputting after compilation ? Do you mean that: > > <Button id="myid" /> - Option is ON > > output will be: > > <Button localId="myid" /> > > I'm sorry if I misunderstand you completely :) > > Thanks, > Piotr > > pt., 2 lis 2018 o 08:31 Greg Dove <greg.d...@gmail.com> napisał(a): > > > 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 > > discussions. > > > > 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 > > this: > > -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 > > here. > > > > -'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. > > > > > > > > 1. > > > > > http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-td54361i40.html#a63276 > > 2. > > > > > http://apache-flex-development.2333347.n4.nabble.com/FlexJS-MXML-ids-and-classNames-td54361i60.html#a63919 > > > > > -- > > Piotr Zarzycki > > Patreon: *https://www.patreon.com/piotrzarzycki > <https://www.patreon.com/piotrzarzycki>* >
