Hi Carlos, I think the more input from you and others we can get on this, the better our final decision will be.
My understanding of what Alex was suggesting is: a) get rid of the current 'localId' implementation b) add a new compiler-only attribute that is recognised on the root tag of the mxml component (up where the namespace declarations are normally expressed) Something like propagateIdsExternally="false/true" (I chose the longest name I could think of - I am sure there are better suggestions). This would affect all 'id' tags in the mxml component making them either all local or all exposed in Html. At least that is what I believe Alex meant. It's definitely worth making sure we are aligned.... On Mon, Nov 5, 2018 at 11:26 AM Carlos Rovira <[email protected]> wrote: > Hi, > > just read all the thread and just want to comment about real Royale > experience that made me enter "localId" world. > Alex, asked if 90% of code will not get multiple ids. My experience says > that people will find lots of them. Why? Let me explain: > > Doing Jewel, and programming Royale components in AS3 never find this > problem due to making things in AS3 and due to the way we code components > we don't need to set ids so you don't find problems. At soon as I started > to code or migrate code from old Flex app, I started to need this when > migrating some component made in MXML. I had many of this that are used > many times thought all Application. > > I expect normal users will do this all the time. For example, a > "SearchBox.mxml" could have a TextInput and a Button, and will have Script > blocks with code that need to deal with the MXML instances declared in that > mxml document (the text input and the button). So the component will > encapsulate all the code that this MXML component will need and eventually > will dispatch some event or accept some external data. Think of this for > many other components like a ON/OFF or YES/NO RadioButton set, or a > identification combobox or dropdownlist with a TextInput to set > identification number, and many many more...those are easy to code in MXML > and people will want to code in MXML and not AS3. > > In the other hand, in Flash we didn't have this problem, but HTML doesn't > allow (by spec) to have more than one id with the same text, So at least in > HTML, and although Browsers doesn't break if users sets non unique Ids, > maybe Royale should Fail on compilation if detects non unique Ids. > > Right now Greg's fix is working, so if we want to iterate over this more we > should take into account that: > > - HTML spec doesn't allow unique ids, so although browsers doesn't enforce > (making your app not running), maybe Royale should fail when compile and > app and find more than one id with the same text. > - CSS: Although we should not requiere id and set CSS with ids, we need to > allow people to set an id and use CSS for that id. We don't use maybe > never, but since is allowed, we should not break that use case from Royale. > - I think people should not use ids in html almost never, but again, we > can't break that use case for people that want to do so, but Royale > shouldn't make the use if ids in HTMLElement something direct or enforce to > make users use that > - For what I see VSCode (that is the IDE I use) is able to do code > intelligence for actual "localId" the same as with normal "id", only thing > is that VSCode can't suggest "localId" since doesn't know about it. Maybe > is a matter to ask Josh to include it the same as "includeIn". > > Since this days I were out, I need to experiment more with the new fix for > localId, so can't say many more about Greg's Boolean flag proposal, or the > removal of localId proposed by Alex in favor of file/project level options > (@Alex, maybe for this you should expose what you have in mind, since I at > least can't envision or imagine what's all about) > > Thanks > > Carlos > > > > > > El dom., 4 nov. 2018 a las 8:24, Alex Harui (<[email protected]>) > escribió: > > > Hi Greg, > > > > I think I've been thinking of it backwards. The compiler had an "id" and > > "effectiveID". Essentlally, explicit references and implicit references. > > The "id" handled databinding and access from script blocks. I don't > think > > the compiler had code to prune CSS id selectors that weren't used, but we > > could have added that. The expectation was that "id"s were going to be > > referenced in code and/or CSS and/or bindings, including references to > the > > component from outside the file, hence "id" had to be a public API. > > > > EffectiveID was used for implicit references. I think it is used in the > > destination of binding expressions. Such as the Label in: > > > > <mx:DateChooser id="dc" /> > > <mx:Label text="{dc.selectedDate}" /> > > > > I think effectiveIDs are generated for some other reasons as well. And > > thus they can be private variables and I don't think they generally > needed > > to dispatch change events. > > > > I didn't think of localId like "id" since it doesn't affect CSS. So I > > thought it could be like effectiveID, and so when I saw your changes the > > first thing I thought of was all of the vars there were now going to be > > getter/setters, but now that I'm thinking about it more, localId probably > > does have to be more like "id". It has to support databinding and > > referencing from other files. So I agree with you now that if we do > > optimize the generated code to only generate binding events if used in a > > binding expression, we should do it for both id and localID. But also, > it > > just occurred to me that we may have to be even smarter and find out if > > folks are setting up bindings or the equivalent in AS code, so I guess we > > should just put that optimization on the back burner for now. > > > > So, I think if you are going to do any more work in this area, it should > > be to get rid of localID and put a per-file option (and optionally, an > > additional compiler option if you want all files in a compilation set) to > > generate different code for "id". > > > > Regarding React and references, I have not played much with React and I > > didn't have time to look at your links today, but it just occurred to me > > that the reason they chose the name React was to switch away from > > procedural programming to functional and/or data-flow programming. That > > was a hot topic around the time that Flex was donated to Apache. Flex > and > > Royale are heavily oriented towards procedural programming. It might be > > interesting someday to see what the impact to Royale of introducing a > > functional or data-flow programming workflow would be, but for now, we > are > > here to leverage all of the tons of existing procedural code out there, > > from the Flex apps being migrated to Royale, the IDEs that are tuned to > > procedural programming, and the vast amounts of procedural JavaScript out > > there as well. > > > > While there are lots of benefits to functional programming, I'm not clear > > that it is as easy to be successful with functional programming compared > to > > procedural programming which is a major factor to our users. Not all of > > our users are trained software engineers and sometimes it is just faster > to > > hack something into working. getElementByID and related APIs rely on > there > > being a "global scope" and IIRC, these other programming models eliminate > > global scopes. It is, in some ways, the same reason that JavaScript was > > way more popular that Java running in a browser. The ability to just > hack > > code until it worked allowed lots of people to ship on time, but the > stuff > > they shipped often lacked structure and would fall down later. > > ActionScript, TypeScript, and friends all added structure without being > as > > structured as Java. This made it possible to ship much more complex > > applications. I have a saying that anyone can take wood and nails and > > build a dog house, but you need structure to build a skyscraper. The > > global scope and procedural programming puts structure in the > instructions > > but does not put structure on access to resources, so it allows you to > > build a skyscraper where every elevator goes from the first floor the > top. > > IMO, functional programming at is purest would only let an elevator go > from > > one floor to the next. > > > > Anyway, unless we hear from someone else, I think you can start in on > > removing "localID" and adding file and, optionally, project level > options. > > > > Thanks, > > -Alex > > > > > > > > On 11/3/18, 1:47 AM, "Greg Dove" <[email protected]> wrote: > > > > Hey Alex, > > Re: > > If you are asking if we should be smart about what code we generate > for > > "id" and only add the binding events if the "id" is used in a source > > expression of a binding expression, then yes, we could do that > > optimization > > as well. > > > > Yes I am - but I don't 'get' why you think about localId in a > > different way > > to regular id here. There could be a gap in my understanding. Maybe I > > am > > not seeing the wood for the trees. For me, they are both *exactly* > the > > same, except one does not set the id on HtmlElement. So id can be > used > > in > > exactly the same way you described in your snippet for localId. In > > which > > case it's also wasteful in exactly the same way, right? If yes, then > > presumably the exact same optimization approach applies to both - > > because > > in the local code (developer's as3, mxml), they are in fact no > > different.... I think? > > > > > > Regarding not using IDs in HTML, IMO, that's not our decision. We > > provide > > the developer choices to set it or not. How should we do it? Since > > you > > and I seem to be thinking this can be controlled at a "whole file" > > level, > > it may be better to get rid of localId and have a per-file directive > to > > dictate whether id gets output as "id" and sets the HTMLElement id or > > "_ld" > > and doesn't. Then we wouldn’t have a magic compile-time property > that > > the > > IDEs have to learn about. > > > > Sure. I wasn't suggesting 'no option' for the developer, just that I > > don't > > consider it (personally) a common need. Others likely may have a > > different > > view because they do things differently or have encountered > situations > > that > > I have not. > > In terms of implementation, yeah I was trying to think of examples > > within > > mxml components where you would actually want to have some with > > localId and > > not others, but nothing sprang to mind. If it's anything where the > > parent > > mxml component is intended to be used with multiple instances, then > you > > very likely want it off for all ids, so thus far I also think file > > level > > makes sense. > > > > At some top level views of the application it may be convenient to > have > > individual tag instances being switchable, but I think I'd be happy > to > > forgo that for a simpler file level implementation. > > If it does remain at instance tag level, then I do think that having > a > > boolean attribute switch alongside the regular id attribute to 'turn > > it on > > or off' for DOM setting makes more sense than a separate localId > > string. > > This doesn't break the usefulness of what IDEs already know about > 'id' > > although the other new compile-time attribute is 'not known' by the > IDE > > unless we can somehow fool the code inspectors. > > > > So yes, I think the file level approach sounds pretty good on the > face > > of > > it. I just think this is also really important to get right, because > it > > won't be easy to change later, so would be keen to see others' > > thoughts too. > > > > Personally I think my own default for most things will be 'off' > > because I > > think it is rare to actually need the ids at the DOM level. > > > > Regarding React: There must be a way to give a component a name in > > their > > markup so you can reference it from script. What is their way of > doing > > that? > > > > Actually most of React considers what we think of as the components > > more > > conceptually as part of the 'rendering', not so much as > > 'instantiations' - > > more like output that derives from properties passed down via the > > parent > > chain, and from local state changes (which triggers 're-render'). > Most > > times it's avoidable to do more than follow that approach. But on the > > occasions you need to get a reference from lower down in the > > 'rendering', > > it uses something called 'refs' which are 'kind of' like localId. > They > > are > > a way for the 'rendered' component to to pass back a reference of > > themselves to something in the parent chain that rendered them. React > > is > > onto (I think) the 3rd implementation of how this can happen, > gradually > > improving things. It used to be passing down a string that was a > field > > to > > set on a special object (this.refs) in the parent, which is now > > officially > > deprecated. Then callbacks were used (like the example link I posted > > earlier). The current best practice passes an object that is defined > > on the > > parent using React.createRef() which is populated with a current > value > > by > > the child. But again, it is relatively rare to use these. You can see > > an > > example in that link I posted earlier an example of the component > doing > > something directly with the HtmlElement (input), using the callback > ref > > approach. ( > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.javascriptstuff.com%2Fuse-refs-not-ids%2F%23the-solution-refs&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=n2%2Bb6%2FAbwY0oOSkDZE1izBXl6GJQjOdr3akzno4jlsI%3D&reserved=0 > > ) > > > > In my experience it is rare to reference anything using markup ids, > > using > > the old document.getElementById. For React, most libraries insulate > you > > from anything to do with that (possibly wrapping some vanilla js lib > to > > make it more React-like) and provide a set of 'props' that you use to > > configure them. If you want to read some possibly biased, but perhaps > > helpful, learning descriptions, you should google 'thinking in > react' - > > you can find a concrete example of some of the things I mentioned. > > Styling > > also tends to be different and happen alongside component code, but I > > won't > > go into details. > > > > There's a lot about React/ReactNative that was strange and different > > to me > > (and I'm still learning new things), but I think it forces a number > of > > patterns that avoid some of the pitfalls of working with js. Just in > > different ways to what I was familiar with. I actually think learning > > it > > has helped me think about Royale in different ways because it also > > forced > > me to learn about related things like webpack and babel etc as well. > > Enough about React.... hopefully I answered your question somewhere > in > > that > > > > > > > > > > On Sat, Nov 3, 2018 at 7:30 PM Alex Harui <[email protected]> > > wrote: > > > > > Hi Greg, > > > > > > If you look at all of the code generated for "id", there is a bunch > > of > > > code in there to support databinding. And so, you are correct that > > if > > > someone binds to something with a localId, then you should generate > > the > > > same code as "id". > > > > > > But my point is that localId can be used for reasons other than > > > databinding, in which case you don't need all of that code. Many > > times, it > > > can just be a plain var. As in: > > > > > > <js:TextInput localId="myTi" change="changedText()"/> > > > <fx:Script> > > > private function changeText():void { > > > sendToServer(myTI.text); > > > } > > > </fx:Script> > > > > > > For the snippet above, it is not necessary to handle localId the > > same as > > > "id". > > > > > > If you are asking if we should be smart about what code we generate > > for > > > "id" and only add the binding events if the "id" is used in a > source > > > expression of a binding expression, then yes, we could do that > > optimization > > > as well. > > > > > > Regarding not using IDs in HTML, IMO, that's not our decision. We > > provide > > > the developer choices to set it or not. How should we do it? > Since > > you > > > and I seem to be thinking this can be controlled at a "whole file" > > level, > > > it may be better to get rid of localId and have a per-file > directive > > to > > > dictate whether id gets output as "id" and sets the HTMLElement id > > or "_ld" > > > and doesn't. Then we wouldn’t have a magic compile-time property > > that the > > > IDEs have to learn about. > > > > > > Regarding React: There must be a way to give a component a name in > > their > > > markup so you can reference it from script. What is their way of > > doing > > > that? > > > > > > Thanks, > > > -Alex > > > > > > On 11/2/18, 4:39 PM, "Greg Dove" <[email protected]> wrote: > > > > > > Thanks Alex, > > > For this: > > > I thought there were two problems: > > > > > > A) a compiler warning about binding to something with a localID > > > B) it didn't work in the js-release version. > > > > > > Issues/Expecations > > > -------------------------- > > > I did not even look at (A) (or notice it if there is one), and > > yes > > > there > > > was an issue with b - minimization of the getter/setter that > > otherwise > > > would normally prevent issues. > > > The binding issue I observed was that binding from outside the > > > component > > > did not work with localId - but it did work when id was used. > > > > > > So my 'fixes' were based on the assumption that the localId > > feature > > > could > > > be specified as: > > > "Same functionality as 'id' but does not set the HtmlElement > id" > > > > > > In other words, I would expect swapping it out simply to change > > the > > > DOM id > > > assignment aspect, and nothing else that already functions > > correctly > > > with > > > 'id' > > > Is this not the original intention? > > > > > > I understand your point about the PAYG aspect and not having a > > bindable > > > getter/setter - but I did not change anything in that > > implementation, I > > > just re-used the original one for 'id' which already does that > - > > so it > > > should behave exactly as if 'id' was used I think (I will check > > this, > > > but I > > > don't think there is already an optimization for id?). I did > > this while > > > testing binding issues when swapping id to localId in code, > > compared > > > across > > > flash and js, aiming for identical results. > > > > > > Let me know if the assumption above ("Same functionality as > 'id' > > but > > > does > > > not set the HtmlElement id") is wrong, but if it is right, then > > I will > > > try > > > to do what you suggested for *both* localId and id in terms of > > > selective > > > getter/setter output based on source.binding optimizations. Not > > sure at > > > this point how easy this will be, but happy to give it a go > > > (timeframe:during November). > > > > > > Alternatives > > > --------------- > > > In terms of my own use, I would prefer 'not setting' > HtmlElement > > id far > > > more routinely than setting it, based on my experience with > > other work > > > over > > > the last 18 months or so. But that's just me (and also my > > experience > > > was > > > using React, not Royale). > > > I just looked at a complex React app in the browser and copied > > out the > > > html > > > in the body tag, and seached for id=" in a few different view > > states. > > > Aside from the top level 'root' tag for the app itself, the > rare > > usages > > > were exclusively with 3rd part libs, none of our own code was > > assigning > > > ids. I'm not suggesting this is always typical, because others > > might > > > have > > > quite opposite views. But it is my experience. > > > (I also just googled 'should you use id in react apps' and > > something > > > sort > > > of similar is expressed here[1] - again just for comparison - > > the > > > 'refs' > > > mentioned is the local reference to the element.) > > > > > > In terms of potential changes to the mxml tag implementation > > itself - > > > in > > > the end, I can definitely work with it how it is - although as > > > mentioned > > > earlier, I also agree that it should be an error to have both > id > > and > > > localId set with the current approach. > > > And I don't want to belabor the point if everyone decides this > is > > > already > > > locked in as-s. > > > But if there is a time to refine or review it, it does seem > > better to > > > do it > > > sooner rather than later. For the IDE aspect, I personally > think > > that > > > should factor more in to the decision about how this is > > implemented, > > > but I > > > did not contribute to the original discussion so that's my > fault! > > > > > > I'm sorry my posts always end up so long. I will try to keep > them > > > shorter. > > > -Greg > > > > > > 1. > > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.javascriptstuff.com%2Fuse-refs-not-ids%2F&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=WpGrZvM%2BJNaxKf%2B%2Bpu2au1C%2FFFFNUkt2C9BV4XPduxg%3D&reserved=0 > > > > > > > > > On Sat, Nov 3, 2018 at 8:03 AM Alex Harui > > <[email protected]> > > > wrote: > > > > > > > Hi Greg, > > > > > > > > I thought there were two problems: > > > > > > > > A) a compiler warning about binding to something with a > localID > > > > B) it didn't work in the js-release version. > > > > > > > > The SWF does not rename variables so I would expect it to > work > > > whether the > > > > localID is a var or bindable getter/setter due to the default > > > > timing/lifecycle. And I believe it works in js-debug > version. > > > > > > > > What converting from var to getter/setter does is add @export > > so that > > > > Google Closure won't rename the localId. So that makes > sense, > > but > > > > converting every localId var to a getter/setter is > non-optimal > > > because not > > > > all localIds are used in binding expressions, so it would be > > great > > > if you > > > > could optimize it by checking to see if the localId was used > > as the > > > source > > > > (not the destination) in a binding expression. But all of > > this is > > > code > > > > that will solve B, and it occurs to me that the compiler > should > > > still be > > > > outputting warnings in A, although we could defer work on > that. > > > > > > > > -Alex > > > > > > > > On 11/2/18, 11:50 AM, "Greg Dove" <[email protected]> > wrote: > > > > > > > > Alex, sorry if I wasn't clear. > > > > > > > > What I meant was this: > > > > 1) The compiler has always had a notion of IDs and > > > effectiveIDs. IDs > > > > reflect the "id" property in an MXML Instance. You set > > id="foo" > > > and > > > > the > > > > compiler will create a getter/setter with bindable events > > named > > > "foo" > > > > on > > > > the output class. > > > > > > > > I was just matching the above id that for localId in js > > with the > > > belief > > > > that they should work the same locally without any other > > changes > > > (in > > > > actionscript/mxml). My changes should only do that for > the > > > localId, > > > > not all > > > > effectiveIds (if not that was not my intention and I will > > fix > > > it). > > > > I assumed this is what was happening in swf because I can > > see the > > > > bindings > > > > working in my side-by-side comparison tests, but it could > > be > > > because of > > > > timing of binding initialization maybe. I will check > this. > > > > I had the impression that id and localId were supposed to > > be > > > > functionally > > > > equivalent, with only the HtmlElement setting not > > happening in > > > js. > > > > Maybe > > > > the > > > > > > > > I will think about how to optimize things. > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Nov 3, 2018 at 7:20 AM Alex Harui > > > <[email protected]> > > > > wrote: > > > > > > > > > Hi Greg, > > > > > > > > > > I’m not sure what you mean by "match the swf behavior". > > I > > > don't > > > > think the > > > > > SWF output generated bindable getter/setters for every > > > effectiveID, > > > > but it > > > > > might already have the smarts to do that for any > > effectiveID it > > > > finds is > > > > > used in a source expression for databinding. In fact, > I > > guess > > > I'm > > > > > surprised that the warning I thought was being > generated > > went > > > away > > > > if you > > > > > only changed the JS output. I thought that warning > came > > from > > > a check > > > > > elsewhere in code that dictates both SWF and JS compile > > errors. > > > > > > > > > > Getters/setters have function call overhead compared > to a > > > plain var, > > > > so > > > > > any time we can skip using them, we have faster smaller > > code. > > > So > > > > Ideally, > > > > > the compiler would only generate getter/setters for > "id" > > when > > > it > > > > absolutely > > > > > has to. So if you can, it would be best to try to make > > that > > > change > > > > a bit > > > > > smarter. There is a BindingDataBase that might contain > > useful > > > > information. > > > > > > > > > > I agree that you can assume multiple instances for an > > MXML > > > file in a > > > > SWC, > > > > > but I'm not clear that everyone generates SWCs for > their > > MXML > > > files. > > > > > > > > > > Anyway, if we can agree that we could essentially treat > > "id" > > > like we > > > > are > > > > > currently treating "localId" for an entire file, then > we > > don't > > > need a > > > > > "localId" compile-time property which would make Royale > > more > > > > compatible > > > > > with existing IDEs. > > > > > > > > > > My 2 cents, > > > > > -Alex > > > > > > > > > > On 11/2/18, 10:58 AM, "Greg Dove" <[email protected] > > > > wrote: > > > > > > > > > > Hi Alex, Thanks for the comprehensive info! > > > > > > > > > > Just a few selective comments: > > > > > > > > > > 'Greg's changes appear to generate bindable > > getter/setters > > > for > > > > all > > > > > localIDs. This will work for now, but IMO, isn't > as > > PAYG > > > as it > > > > could > > > > > be.' > > > > > > > > > > Sorry I was not clear in my understanding if this > was > > > > intentionally > > > > > omitted. I thought that localId was the same as id, > > but > > > just > > > > avoids the > > > > > HTMLElement id setting. So I expected switching id > to > > > localId to > > > > > continue > > > > > to work the same but fix the browser console > > duplicate id > > > > alerts. That > > > > > is > > > > > what I was addressing here. But I think my changes > > in js > > > match > > > > the swf > > > > > behavior now? > > > > > > > > > > I'm not proposing anything added to UIBase, just a > > > different way > > > > to > > > > > implement the compile-time feature. > > > > > > > > > > 'One question I have is whether the developer of an > > MXML > > > > Component > > > > > "knows" > > > > > that the component is intended to have multiple > > instances > > > or > > > > not. If > > > > > not, > > > > > the problem gets harder, as the generated output > > need to > > > be told > > > > > whether to > > > > > set the HTMLElement id or not. If the developer > > "knows", > > > we > > > > could find > > > > > some way to tell the compiler to generate all "Id" > > as what > > > we are > > > > > currently > > > > > generating for "localId". ' > > > > > > > > > > If the MXML Component is part of a swc, it is > safest > > to > > > assume > > > > that it > > > > > is > > > > > possible to have multiple instances I think. But > not > > > really known > > > > > (although > > > > > some component types can be assumed to be likely). > > > > > > > > > > 'Thinking about it now, I can't think of why, in a > > single > > > MXML > > > > file, > > > > > you > > > > > would need to sometimes set "id" and other times > set > > > "localId". > > > > I > > > > > think > > > > > either you want all ids in a file to not set the > > > HTMLElement ids > > > > or > > > > > not. ' > > > > > > > > > > This seems true also, thinking about it - that's > good > > > insight. > > > > > > > > > > > > > > > > > > > > On Sat, Nov 3, 2018 at 6:25 AM Alex Harui > > > > <[email protected]> > > > > > wrote: > > > > > > > > > > > Greg's suggestion is valid. And there could > > certainly > > > be a > > > > better > > > > > > solution than "localID". But maybe we need > > agreement on > > > the > > > > problem > > > > > space > > > > > > first. > > > > > > > > > > > > IMO, the problem of multiple IDs is rare. Can we > > agree > > > on > > > > that? My > > > > > guess > > > > > > is that 90% of .MXML files never have more than > one > > > instance > > > > of them > > > > > on > > > > > > screen at a time. > > > > > > > > > > > > So, if we can agree on that, then we want to > apply > > PAYG > > > to the > > > > > solution. > > > > > > We want folks to be able to create an MXML file > > for the > > > 90% > > > > case, > > > > > use IDs, > > > > > > use CSS and third-party libraries that call > > > getElementById and > > > > > things "just > > > > > > work". Hopefully, we can agree that it is ok for > > more > > > work to > > > > be > > > > > required > > > > > > by the developer and more code to be generated > and > > run > > > to have > > > > > multiple > > > > > > instances of an MXML file on screen. > > > > > > > > > > > > Technically there are two sections of code that > > factor > > > into > > > > this: > > > > > > > > > > > > 1) The compiler has always had a notion of IDs > and > > > > effectiveIDs. IDs > > > > > > reflect the "id" property in an MXML Instance. > > You set > > > > id="foo" and > > > > > the > > > > > > compiler will create a getter/setter with > bindable > > > events named > > > > > "foo" on > > > > > > the output class. This is super important in > > Flash since > > > > classes are > > > > > > sealed (not dynamic) and so you must declare > slots > > to > > > hold > > > > > references to > > > > > > instances on the output class. But there are > cases > > where > > > an > > > > instance > > > > > is > > > > > > referenced by some other piece of the MXML file > > but the > > > > developer > > > > > did not > > > > > > specify an id. Binding expressions can do that. > > I think > > > > there are > > > > > other > > > > > > scenarios, but I can't think of them right now. > > In these > > > > cases the > > > > > > compiler generates an effectiveID and a simple > > private > > > var on > > > > the > > > > > output > > > > > > class for every effectiveID. In the MXML output, > > the > > > > effectiveID is > > > > > given > > > > > > the property name "_id". > > > > > > > > > > > > 2) The framework code has UIBase with an "id" > > property > > > setter > > > > that > > > > > sets > > > > > > the id on the HTMLElement. In addition, the > > > > MXMLDataIntepreter has > > > > > logic > > > > > > that tests if a property being set on an instance > > is > > > named > > > > "id" or > > > > > "_id". > > > > > > If "id", additional logic sets the slot on the > > document > > > and > > > > sets the > > > > > "id" > > > > > > property on the instance to set the HTMLElement's > > id. If > > > > "_id", it > > > > > only > > > > > > sets the slot on the document, but not the > > instance, > > > since it > > > > could > > > > > assume > > > > > > that no other code should care that the instance > > has its > > > id > > > > set (and > > > > > thus, > > > > > > for browser versions, whether the HTMLElement id > > is set). > > > > > > > > > > > > "localId" is a "compile-time property". It is > one > > of a > > > few > > > > > properties > > > > > > that don't actually exist on the instance's > > ActionScript > > > > > implementation. > > > > > > Other examples are "includeIn" and "excludeFrom" > > for > > > states. > > > > So, the > > > > > > localId" doesn't introduce a new problem for > IDEs, > > they > > > all > > > > had to > > > > > deal > > > > > > with includeIn/excludeFrom already, but it is > true > > that > > > IDEs > > > > still > > > > > need to > > > > > > learn about it. > > > > > > > > > > > > The localID implementation before Greg's changes > > > leveraged the > > > > > effectiveID > > > > > > aspect of all of this code. It did not generate > > bindable > > > > > getter/setters > > > > > > "just in case" the element with the localID was > > used in > > > > Bindings. > > > > > It did > > > > > > not set the instance's id which would run code to > > set the > > > > > HTMLElement's > > > > > > id. However, if the element with a localId was > > used in a > > > > binding > > > > > > expression then you would get a warning. > > > > > > > > > > > > Greg's changes appear to generate bindable > > > getter/setters for > > > > all > > > > > > localIDs. This will work for now, but IMO, isn't > > as > > > PAYG as it > > > > > could be. > > > > > > Ideally, the compiler would find out if the > > localID is > > > used in > > > > the > > > > > source > > > > > > expression of a binding expression and only then > > > generate the > > > > > bindable > > > > > > getter/setter. FWIW, another possible fix would > > be to > > > > suppress the > > > > > > warning, but there might be a timing issue around > > > effectveIDs > > > > used in > > > > > > states. > > > > > > > > > > > > IMO, any proposal to add another actual property > > on every > > > > instance of > > > > > > UIBase "just-in-case" someone is going to use > > multiple > > > > instances of > > > > > an MXML > > > > > > file doesn't seem PAYG to me. This is why we > > originally > > > chose > > > > the > > > > > current > > > > > > implementation. Any proposal that makes the > > setter for > > > "id" > > > > do an > > > > > extra > > > > > > check "just-in-case" the instance is used in > > multiple > > > > instances of > > > > > an MXML > > > > > > file doesn't seem PAYG to me either. We could > > change the > > > > meaning > > > > > of, or > > > > > > name of "localID", but then it is still a > > compile-time > > > > property that > > > > > IDE's > > > > > > have to handle. > > > > > > > > > > > > One question I have is whether the developer of > an > > MXML > > > > Component > > > > > "knows" > > > > > > that the component is intended to have multiple > > > instances or > > > > not. > > > > > If not, > > > > > > the problem gets harder, as the generated output > > need to > > > be > > > > told > > > > > whether to > > > > > > set the HTMLElement id or not. If the developer > > > "knows", we > > > > could > > > > > find > > > > > > some way to tell the compiler to generate all > "Id" > > as > > > what we > > > > are > > > > > currently > > > > > > generating for "localId". Thinking about it > now, > > I > > > can't > > > > think of > > > > > why, in > > > > > > a single MXML file, you would need to sometimes > > set "id" > > > and > > > > other > > > > > times > > > > > > set "localId". I think either you want all ids > > in a > > > file to > > > > not > > > > > set the > > > > > > HTMLElement ids or not. > > > > > > > > > > > > And if that's true, then we can think of ideas to > > treat > > > the id > > > > > property in > > > > > > a file instead of a per-MXML-tag way. One way > to > > do > > > that is a > > > > > compiler > > > > > > option, but then you would have to compile that > > MXML file > > > > separately > > > > > (or > > > > > > with other multi-instance MXML files). Another > is > > some > > > sort of > > > > > > "directive", maybe metadata or a special comment. > > In AS > > > > files, we > > > > > already > > > > > > have special metadata and comments for compiler > > > directives. > > > > > > > > > > > > Of course, I could be wrong... > > > > > > -Alex > > > > > > > > > > > > On 11/2/18, 10:13 AM, "Greg Dove" < > > [email protected]> > > > wrote: > > > > > > > > > > > > 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 > > < > > > > > > [email protected]> > > > > > > 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 < > > > [email protected]> > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.2333347.n4.nabble.com%2FFlexJS-MXML-ids-and-classNames-td54361i40.html%23a63276&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=7xB6qx%2F6M8L%2FNneQg2xnr999g7BFlFHZjbtm86v%2Bj1w%3D&reserved=0 > > > > > > > > 2. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.2333347.n4.nabble.com%2FFlexJS-MXML-ids-and-classNames-td54361i60.html%23a63919&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=NhHoBRQX5b6GcypvyXgIm%2F7obQZZS%2BwLNHg3moD0JJM%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Piotr Zarzycki > > > > > > > > > > > > > > Patreon: * > > > > > > > > > > > > > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=Qx1%2FIQYZuTA8uGDDtiFPrN1Kv5sl%2FYq25VKKSM9X9TE%3D&reserved=0 > > > > > > > < > > > > > > > > > > > > > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=Qx1%2FIQYZuTA8uGDDtiFPrN1Kv5sl%2FYq25VKKSM9X9TE%3D&reserved=0 > > > > > > >* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira >
