The underlying JS runtimes are highly tolerant of bad code. We should be too, IMO.
I get it. But please let's not make that the marketing slogan :) On Mon, Nov 5, 2018 at 8:39 PM Alex Harui <[email protected]> wrote: > IMO, the benefit of choosing "words" instead of "true/false" "on/off" > Booleans is that you can invent new allowed values later. So if some other > platform does come into play, we can add other allowed values and even a > comma-separated list of allowed values. So we can be explicit that we > have an option that sets IDs on HTMLElements for now and be explicit about > what we might make it do for other platforms later. And the doc for the > new platform can specify whether old options apply or not. > > Regarding setting ids on HTMLElement in the first place: While we often > talked about Flex as a Framework, lately, I'm thinking of Royale as a > "workflow". Royale could turn out to be the most efficient way for people > to glue together existing chunks of JavaScript. Or at least, the way that > folks who program in other languages (Java, C, others?) are familiar with. > The "framework" aspect of Royale is de-emphasized because Royale supports > multiple "frameworks" or "component sets". > > A "component set" is a bunch of existing JavaScript, and the code the > application developer writes glues it together. Good or bad, I think there > is a ton of existing chunks of JavaScript that use HTMLElement.id and "just > works". I am hopeful that Royale will never try to tell folks how write > their code. That's why I wouldn't be in favor of switching to > all-functional-programming, or not allowing some kinds of circular > dependencies. Users should be able to "harden" their existing code by > specifying a strongly-typed API/Typedefs/Externs for the existing chunks of > code, write some code to glue it to other code, and get it up and running > faster because our workflow will catch certain errors earlier. > > We can/should provide advice and guidance on best practices, but I think > we'll do better by not requiring that folks conform to those best > practices. The underlying JS runtimes are highly tolerant of bad code. We > should be too, IMO. > > My 2 cents, > -Alex > > On 11/4/18, 11:02 PM, "Greg Dove" <[email protected]> wrote: > > Yeah I guess it might be overdoing it a bit. But I was trying to think > of a > way to maximize the possibility of meeting everyone's needs, even if > it was > a more simplistic implementation first that only evolved on demand. > > I had considered the issue with swcs being 'fixed'. That's why I > mentioned > that an App level policy only applies to mxml documents in the 'local > project' and that it can only be used at an App level. > > Anyway it seems like we are thinking in the same general direction. > > fyi I chose external or localOnly examples because I actually thought > it > should not be specific in meaning to 'Html'. No, I don't have any magic > suprise new targets, but maybe if it is too specific to Html in > meaning it > won't make sense for whatever comes later (hopefully). Beyond those > initial > thoughts I don't actually have a strong preference for what they get > called, so anyone else reading this please offer suggestions. I'm > going to > leave this thread for a bit now to hopefully collect any other > feedback, > and check back in a week or so. I'll start work on it then. > > > > > I still don't get the emphasis on styling by id given that it is > completely > avoidable. > > > On Mon, Nov 5, 2018 at 7:30 PM Alex Harui <[email protected]> > wrote: > > > Hi Greg, > > > > IMO, that's too fancy, but I won't object if that's what you really > want > > to implement. We'll find out when people try to use it. IMO, you > could > > just allow [DocumentIDPolicy] without the appliedTo in any MXML > file, and > > have some sort of compiler-option for "whole project". > > > > Technically, the main App might be compiled separately from the MXML > > components that care about the id policy, and changing it in the > main app > > will not affect MXML components already compiled in SWCs, so that's > why I > > would just have metadata specify something for the file it is in and > leave > > it for compiler options to handle per-project. Also, there is no > main file > > in many COMPC SWC compiles so you wouldn't have a place to hang the > > [DefaultIDPolicy]. > > > > Also, I'm not sold on the choice of "external" vs "local", because, > IMO, > > it should be ok for the id to be accessed externally. What we > really want > > to control is whether the id sets the CSS id or not, so I would be > explicit > > about that in the choices. Maybe "css" vs "none". Or > "HTMLElement" vs > > "document". Not sure. > > > > HTH, > > -Alex > > > > On 11/4/18, 9:36 PM, "Greg Dove" <[email protected]> wrote: > > > > Actually I was thinking the same.... I wrote up some thoughts > earlier > > today. > > > > Something like: > > > > Only permitted (once only) in the main App's mxml: > > > > <fx:Metadata> > > [DefaultIdPolicy(policy="external|localOnly")] > > </fx:Metadata> > > > > -policy parameter is mandatory. > > Basic options are either default to external or default to > localOnly. > > If this metadata is not expressed in main document, it could be > > defined via > > a default setting from compiler config. > > This policy applies to all mxml documents in the local project > unless > > they > > specify their own document level policy (which the main app mxml > can > > also > > do) > > > > > > Permitted (once only) in any mxml document > > If specified in an mxml document, the global default policy does > not > > apply > > to that document, and the locally defined policy applies. > > > > <fx:Metadata> > > [DocumentIdPolicy(policy="external|localOnly",appliesTo="csv > of > > id")] > > </fx:Metadata> > > > > -policy parameter is mandatory. > > -appliesTo parameter is optional, and if omitted, is the same as > > 'applies > > to all in this document' > > Otherwise if a valid csv of ids is provided via appliesTo, the > compiler > > would apply the Document policy to those ids. In this case the > opposite > > policy would be applied to any other ids not in the csv. > > It could show an error or warning if any ids in the csv list are > > repeated > > or are not valid for the current document. > > > > The appliesTo implementation could be omitted initially and > added later > > only if we need it, again without breaking anything, I think. > > > > The metadata approach could also be helpful in any js DOM > 'tools' that > > inspect the DOM and report duplicate ids back to the developer. > If > > reflection data output includes the metadata, I think it should > be > > able to > > report the issue and tell the developer what to change in which > mxml > > document to fix it. In regular builds it could be excluded, so it > > would not > > normally appear in the reflection data unless required (and > therefore > > costs > > nothing in terms of PAYG). > > > > > > On Mon, Nov 5, 2018 at 6:03 PM Alex Harui > <[email protected]> > > wrote: > > > > > Hi Greg, > > > > > > We agree on a). We agree on the goal of "b", but I'm not > clear that > > a > > > compiler-only attribute is the right implementation. Any new > > compile-time > > > property will again introduce the problem that IDEs won't > understand > > it. > > > We have "Royale-only" compiler directives in AS3 via special > ASDoc > > tags > > > (such as @royaleignorecoercion) and metadata (such as > [SWFOverride]) > > > already so I would be tempted to use special comments or > metadata in > > MXML > > > to trigger whether the generated code tries to set the "id" > property > > of the > > > component or not. > > > > > > And FWIW, my nomination for the directive name is > @royaleInoCSSIDs or > > > [NoCSSIDs]. I guess I would lean toward metadata. > > > > > > My 2 cents, > > > -Alex > > > > > > On 11/4/18, 2:54 PM, "Greg Dove" <[email protected]> wrote: > > > > > > 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%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668055788&sdata=KJvnJ8unZTHxODVtPCoSZTl6AzDA811u1jjevqWcDvQ%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%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&sdata=7e8%2F8klA6zgaKtZT4iwcasHRnUHp7zW2HxKU9siIEN4%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%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&sdata=YmdX8%2Btd1fhFvuzPyMCRuv9y1WecYXrUztaUhEGlFt0%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%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&sdata=o0LQMf6MQEi1wTuqWe0NJ6VgwJu16PnrKJiGeTVnDt0%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%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&sdata=wYnMDe%2BeH3hkOXX3bS3CmtHmTzYWTnag4lQPzGU%2ByYs%3D&reserved=0 > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&sdata=wYnMDe%2BeH3hkOXX3bS3CmtHmTzYWTnag4lQPzGU%2ByYs%3D&reserved=0 > > > > > > > > > >* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Carlos Rovira > > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&sdata=Wcsqb%2FUYANkIUWV7H0Gjo4cPeAtdPHakiBIMHs7TenI%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > >
