Hi, after working with id - localId after some days, I start to see what's comfortable, and what not, and gets more to the core point.
I think that having two of this: id and localId, is strange, since I as a user, only wants one, and that one be unique in my application. In Flash this was no brainer and worked ok. In HTML since all is in the same page, we have this problem, so I think that the best scenario for me as a user would be: * get rid of "localId" in favor of only one "id" * that id works as localId and work *internaly" and not declared in html * this should be how it works for JS, SWF and if not wrong for the rest of targets we could add but how to deal with the need to set up an id in HTML? ok, since this is for me the side case, I'll vote for an "htmlId" property that could be set in AS3/MXML and that could be (if I'm not wrong) as a new framework property (maybe in HTMLElementWrapper?). So users could reference this id from CSS, in case they needed. Can't think in a simplest way to deal with this. The cons of the actual way is that I have all my user code populated with lots of "localId" and in other places still "id", what seems to something Royale should take care of, and instead of that users will need to be worried about something that is one of the things a framework must do for you. So I think we need to fix that to make it less cumbersome. At last, that's one of the reasons why people choose frameworks right? :) Thoughts? Carlos El lun., 5 nov. 2018 a las 9:07, Greg Dove (<[email protected]>) escribió: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Carlos Rovira http://about.me/carlosrovira
