Hi Alex, Thanks for sumarizing the proposal:
El mié., 7 nov. 2018 a las 18:10, Alex Harui (<[email protected]>) escribió: > Hi Carlos, > > Did you have some sort of objection to what Greg and I seem to agree on? > I write after some days of experience with localId, so didn't try to compare with other things proposed in this thread, just give a separate opinion. Go no through your points: > > It is: > 1) get rid of localId. > Right. I think we only need "id". just having two is cumbersome and less natural and people coming to royale probably will not know about it. > 2) Provide a compiler option to generate code where "id" sets > HTMLElement.id or not > this is not much clear to me. Since the problem seems related only to HTML (correct me if I'm wrong). Don't will be better to have a COMPILE::JS var called for example "htmlId" at HTMLElementWrapper level so people can set if they want? We must think that the use of this var will be very rare and people should use only to reference it from CSS (so we maintain compatibility with HTML). These seems for me much granular and less problematic that implement a whole new compiler var. We should try to minimize compiler vars at a minimum or compiler will end having many vars and difficult to manage. > 3) Provide metadata to control whether generated code sets HTMLElement.id > or not on a per-file basis > Again seems to me very complex solution for something that could be solved making "id" local and having the JS only "htmlId". This seems more simple and cover the side case for people that wants to write the id in the html element when needed. > 4) Default is to generate code that sets HTMLElement.id. > mmm...I think it should be the opposite. We only want "id" in HTML when required (most of the time never!), so only people that really want to have id cause want to use CSS or JS could write it. > > The reason for #4 is because we want folks to be able to grab and use > existing code. Probably some code should be adapted if we want to go with my proposal. For example in Jewel, navigation components uses "id", so there I should use the "htmlId". > Flex code had "id" tied to CSS ID Selectors. Could make MX and Spark emulation use "htmlId" for this cases? > You will be able to change that behavior for your code with a compiler > option or per-file metadata. > I think my proposal is more easy and for Royale users, but seems could support Flex migrations. I think we should try something as easy as possible. But I'm only sharing my real world experience and what I see as the most easy solution. If Greg and you like something of what I propose feel free to take it, I think you guys have much more experience and sure you'll get the best solution by far. Thanks > > Thanks, > -Alex > > On 11/7/18, 8:14 AM, "Carlos Rovira" <[email protected]> wrote: > > 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%7C012ba8175b324bc51a2c08d644cc02a4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772040486663199&sdata=vKF%2FwSCdLcpX9xz%2BReM8YuZIwF2k3xTd83%2Bu5jYEzfc%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%7C012ba8175b324bc51a2c08d644cc02a4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772040486673208&sdata=QUkrfZsdgmiQZEEWzTyqOVrhU6t7b8lhij40rRnyN0E%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%7C012ba8175b324bc51a2c08d644cc02a4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772040486673208&sdata=wLzdzQdqHSbQTX34NPz7F5IOmOo1xNnclm%2BjpgfHqbU%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%7C012ba8175b324bc51a2c08d644cc02a4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772040486673208&sdata=rolaVH%2FK%2B0KKbVF9D0pp4ne%2BNzaS%2FubkeOxqJCGwQ6w%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%7C012ba8175b324bc51a2c08d644cc02a4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772040486673208&sdata=1hkn15Z3zA0u1S0xPXDI1rW7DMMWJXlGliW1kr50Pw8%3D&reserved=0 > > > > > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C012ba8175b324bc51a2c08d644cc02a4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772040486683213&sdata=Be73rYvvTPxSZ0NqpX8IpnDHQbVsmbEj1FbUj7oopY4%3D&reserved=0 > > > > > > > > > > > >* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Carlos Rovira > > > > > > > > > > > > > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C012ba8175b324bc51a2c08d644cc02a4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772040486683213&sdata=XmUaVLHuQtOrqjY5UAW%2F7M3aJs00nBM%2B5uxO2V5IKoo%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C012ba8175b324bc51a2c08d644cc02a4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772040486683213&sdata=XmUaVLHuQtOrqjY5UAW%2F7M3aJs00nBM%2B5uxO2V5IKoo%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
