royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: Revisiting the old debate: 'localId vs. id'
Date Mon, 05 Nov 2018 07:39:20 GMT
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" <greg.dove@gmail.com> 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 <aharui@adobe.com.invalid> 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" <greg.dove@gmail.com> 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 <aharui@adobe.com.invalid>
    > 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" <greg.dove@gmail.com> 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 <
    > carlosrovira@apache.org
    >     > >
    >     >     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
    >     > (<aharui@adobe.com.invalid>)
    >     >     > 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" <greg.dove@gmail.com>
    > 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&amp;data=02%7C01%7Caharui%40adobe.com%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668055788&amp;sdata=KJvnJ8unZTHxODVtPCoSZTl6AzDA811u1jjevqWcDvQ%3D&amp;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
    >     > <aharui@adobe.com.invalid>
    >     >     > > 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" <greg.dove@gmail.com>
    >     > 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&amp;data=02%7C01%7Caharui%40adobe.com%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&amp;sdata=7e8%2F8klA6zgaKtZT4iwcasHRnUHp7zW2HxKU9siIEN4%3D&amp;reserved=0
    >     >     > >     >
    >     >     > >     >
    >     >     > >     >     On Sat, Nov 3, 2018 at 8:03 AM Alex Harui
    >     >     > > <aharui@adobe.com.invalid>
    >     >     > >     > 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" <
    > greg.dove@gmail.com
    >     > >
    >     >     > 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
    >     >     > >     > <aharui@adobe.com.invalid>
    >     >     > >     >     > 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" <
    >     > greg.dove@gmail.com
    >     >     > >
    >     >     > > 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
    >     >     > >     >     > <aharui@adobe.com.invalid>
    >     >     > >     >     >     > 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" <
    >     >     > > greg.dove@gmail.com>
    >     >     > >     > 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
    >     >     > > <
    >     >     > >     >     >     >     > piotrzarzycki21@gmail.com>
    >     >     > >     >     >     >     >     wrote:
    >     >     > >     >     >     >     >
    >     >     > >     >     >     >     >     > Hi Greg,
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > I'm really happy that you are
    > helping
    >     >     > Carlos
    >     >     > > with
    >     >     > >     > that!
    >     >     > >     >     > He may
    >     >     > >     >     >     > move
    >     >     > >     >     >     >     > forward
    >     >     > >     >     >     >     >     > much faster. I just have
    > question to
    >     >     > > following:
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > "-My understanding is that best
    >     > practice is
    >     >     > > to
    >     >     > >     > avoid
    >     >     > >     >     > multiple
    >     >     > >     >     >     >     > identical ids
    >     >     > >     >     >     >     >     > in the browser, irrespective of
    >     > whether the
    >     >     > >     > browser is
    >     >     > >     >     >     > forgiving of
    >     >     > >     >     >     >     > that or
    >     >     > >     >     >     >     >     > not. If so, it might be good
    > to have
    >     > at
    >     >     > > least an
    >     >     > >     > option
    >     >     > >     >     > to set
    >     >     > >     >     >     > the
    >     >     > >     >     >     >     > default
    >     >     > >     >     >     >     >     > implementation to support 'best
    >     > practice'
    >     >     > > (DOM ids
    >     >     > >     > 'off'
    >     >     > >     >     > by
    >     >     > >     >     >     > default,
    >     >     > >     >     >     >     > 'on'
    >     >     > >     >     >     >     >     > explicitly, to avoid
    > 'duplicate ids
    >     > by
    >     >     > > accident').
    >     >     > >     > Maybe
    >     >     > >     >     > some
    >     >     > >     >     >     > sort of
    >     >     > >     >     >     >     >     > import wizard for a legacy flex
    >     > project
    >     >     > > could do
    >     >     > >     >     > something
    >     >     > >     >     >     > like this
    >     >     > >     >     >     >     > in an
    >     >     > >     >     >     >     >     > IDE by default though. But it
    > could
    >     > be a
    >     >     > > compiler
    >     >     > >     > config
    >     >     > >     >     > thing
    >     >     > >     >     >     > too
    >     >     > >     >     >     >     >     > perhaps."
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > Does your idea is saying that
    > if I
    >     > have
    >     >     > some
    >     >     > > Flex
    >     >     > >     > app or
    >     >     > >     >     > even
    >     >     > >     >     >     > write
    >     >     > >     >     >     >     > some on
    >     >     > >     >     >     >     >     > my own setting that option to
    > ON -
    >     > change
    >     >     > > the  way
    >     >     > >     > how
    >     >     > >     >     > things
    >     >     > >     >     >     > are
    >     >     > >     >     >     >     >     > outputting after compilation ?
    > Do
    >     > you mean
    >     >     > > that:
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > <Button id="myid" /> - Option
    > is ON
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > output will be:
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > <Button localId="myid" />
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > I'm sorry if I misunderstand
    > you
    >     > completely
    >     >     > > :)
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > Thanks,
    >     >     > >     >     >     >     >     > Piotr
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > pt., 2 lis 2018 o 08:31 Greg
    > Dove <
    >     >     > >     > greg.dove@gmail.com>
    >     >     > >     >     >     > napisał(a):
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > > In collaboration with
    > Carlos, I
    >     > worked
    >     >     > on a
    >     >     > >     > compiler
    >     >     > >     >     > fix for
    >     >     > >     >     >     > some
    >     >     > >     >     >     >     > issues
    >     >     > >     >     >     >     >     > > identified with localId in
    > the
    >     > javascript
    >     >     > >     > output. I
    >     >     > >     >     > pushed
    >     >     > >     >     >     > that a
    >     >     > >     >     >     >     > short
    >     >     > >     >     >     >     >     > > while ago. This fixes
    >     >     > >     >     >     >     >     > > -binding into the localId
    > (in my
    >     > local
    >     >     > test
    >     >     > >     > cases) and
    >     >     > >     >     >     >     >     > > -some occasional issues with
    >     > referencing
    >     >     > > the
    >     >     > >     > instance
    >     >     > >     >     > from
    >     >     > >     >     >     > within
    >     >     > >     >     >     >     > script
    >     >     > >     >     >     >     >     > > blocks in release (minified)
    > code.
    >     >     > >     >     >     >     >     > > Or at least, it does so for
    > the
    >     > cases I
    >     >     > > have been
    >     >     > >     >     > testing. If
    >     >     > >     >     >     >     > anyone else
    >     >     > >     >     >     >     >     > > sees remaining issues with
    > this
    >     > feature
    >     >     > > that
    >     >     > >     > need more
    >     >     > >     >     >     > attention,
    >     >     > >     >     >     >     > please
    >     >     > >     >     >     >     >     > > let me know.
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > Now on to the 'subject' :
    >     >     > >     >     >     >     >     > > As part of 'getting
    > familiar' with
    >     > this I
    >     >     > > went
    >     >     > >     > back to
    >     >     > >     >     > read
    >     >     > >     >     >     > old
    >     >     > >     >     >     >     > threads
    >     >     > >     >     >     >     >     > > about 'id v.s localId'.
    >     >     > >     >     >     >     >     > > I *think* these [1] [2] were
    > the
    >     > main
    >     >     > > ones, but
    >     >     > >     > maybe I
    >     >     > >     >     >     > missed
    >     >     > >     >     >     >     > some other
    >     >     > >     >     >     >     >     > > discussions.
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > After reading these, I
    > wondered if
    >     > anyone
    >     >     > > had
    >     >     > >     > changed
    >     >     > >     >     > their
    >     >     > >     >     >     > views
    >     >     > >     >     >     >     > about
    >     >     > >     >     >     >     >     > the
    >     >     > >     >     >     >     >     > > implementation as it is,
    > after
    >     > having
    >     >     > used
    >     >     > > it
    >     >     > >     > for a
    >     >     > >     >     > while.
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > It may be too late to change
    >     > things, but
    >     >     > > here
    >     >     > >     > are my
    >     >     > >     >     > quick
    >     >     > >     >     >     >     > thoughts about
    >     >     > >     >     >     >     >     > > this:
    >     >     > >     >     >     >     >     > > -My understanding is that
    > best
    >     > practice
    >     >     > is
    >     >     > > to
    >     >     > >     > avoid
    >     >     > >     >     > multiple
    >     >     > >     >     >     >     > identical
    >     >     > >     >     >     >     >     > ids
    >     >     > >     >     >     >     >     > > in the browser, irrespective
    > of
    >     > whether
    >     >     > the
    >     >     > >     > browser is
    >     >     > >     >     >     > forgiving
    >     >     > >     >     >     >     > of that
    >     >     > >     >     >     >     >     > or
    >     >     > >     >     >     >     >     > > not. If so, it might be good
    > to
    >     > have at
    >     >     > > least an
    >     >     > >     >     > option to
    >     >     > >     >     >     > set the
    >     >     > >     >     >     >     >     > default
    >     >     > >     >     >     >     >     > > implementation to support
    > 'best
    >     > practice'
    >     >     > > (DOM
    >     >     > >     > ids
    >     >     > >     >     > 'off' by
    >     >     > >     >     >     >     > default, 'on'
    >     >     > >     >     >     >     >     > > explicitly, to avoid
    > 'duplicate
    >     > ids by
    >     >     > >     > accident').
    >     >     > >     >     > Maybe
    >     >     > >     >     >     > some sort
    >     >     > >     >     >     >     > of
    >     >     > >     >     >     >     >     > > import wizard for a legacy
    > flex
    >     > project
    >     >     > > could do
    >     >     > >     >     > something
    >     >     > >     >     >     > like
    >     >     > >     >     >     >     > this in
    >     >     > >     >     >     >     >     > an
    >     >     > >     >     >     >     >     > > IDE by default though. But it
    >     > could be a
    >     >     > > compiler
    >     >     > >     >     > config
    >     >     > >     >     >     > thing too
    >     >     > >     >     >     >     >     > perhaps.
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > -I can't think of a scenario
    > where
    >     > I
    >     >     > would
    >     >     > > want
    >     >     > >     > to set
    >     >     > >     >     > both
    >     >     > >     >     >     > id and
    >     >     > >     >     >     >     >     > localId
    >     >     > >     >     >     >     >     > > at the same time or what
    > doing so
    >     > would
    >     >     > > mean.
    >     >     > >     > Either
    >     >     > >     >     > you
    >     >     > >     >     >     > want to
    >     >     > >     >     >     >     > set the
    >     >     > >     >     >     >     >     > > DOM id or you don't, in
    > which case
    >     >     > missing
    >     >     > > id and
    >     >     > >     >     > defined
    >     >     > >     >     >     > localId
    >     >     > >     >     >     >     > is more
    >     >     > >     >     >     >     >     > > like a boolean for not
    > setting DOM
    >     > id
    >     >     > (the
    >     >     > >     >     > implementation is
    >     >     > >     >     >     > not,
    >     >     > >     >     >     >     > but to
    >     >     > >     >     >     >     >     > me
    >     >     > >     >     >     >     >     > > it seems that it could -maybe
    >     > should-
    >     >     > be).
    >     >     > > Maybe
    >     >     > >     > I am
    >     >     > >     >     > missing
    >     >     > >     >     >     >     > something
    >     >     > >     >     >     >     >     > > here.
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > -'id' is the basis for code
    >     >     > >     > completion/intelligence in
    >     >     > >     >     > legacy
    >     >     > >     >     >     >     > IDEs. Using
    >     >     > >     >     >     >     >     > > 'localId' means this does
    > not work
    >     > in the
    >     >     > > legacy
    >     >     > >     > IDEs
    >     >     > >     >     > and
    >     >     > >     >     >     > newer
    >     >     > >     >     >     >     > IDEs need
    >     >     > >     >     >     >     >     > > to add custom support for it.
    >     > Anything
    >     >     > that
    >     >     > >     > keeps 'id'
    >     >     > >     >     > as the
    >     >     > >     >     >     >     > primary
    >     >     > >     >     >     >     >     > local
    >     >     > >     >     >     >     >     > > identifier seems like the
    > best way
    >     > to get
    >     >     > > more
    >     >     > >     > life
    >     >     > >     >     > out of
    >     >     > >     >     >     > legacy
    >     >     > >     >     >     >     > IDEs.
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > So to me, the simplest option
    >     > seems to be
    >     >     > > more
    >     >     > >     > along
    >     >     > >     >     > the
    >     >     > >     >     >     > lines of
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > <Instance id="myLocalOnlyId"
    >     >     > > localId="true" />
    >     >     > >     >     >     >     >     > > <Instance id="myLegacyId"
    >     > localId="false"
    >     >     > > />
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > Semantically it is probably
    > better
    >     > as
    >     >     > >     > 'localIdOnly'
    >     >     > >     >     > for the
    >     >     > >     >     >     > boolean
    >     >     > >     >     >     >     >     > > setting, but 'localId' is
    > shorter
    >     > (which
    >     >     > is
    >     >     > >     > perhaps
    >     >     > >     >     > better).
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > In this case, you get more
    > mileage
    >     > from
    >     >     > > older
    >     >     > >     > IDEs,
    >     >     > >     >     > and a
    >     >     > >     >     >     > simpler
    >     >     > >     >     >     >     >     > > implementation for updating
    > IDEs to
    >     >     > handle
    >     >     > > the
    >     >     > >     > extra
    >     >     > >     >     >     > mxml-only
    >     >     > >     >     >     >     > boolean
    >     >     > >     >     >     >     >     > > setting. In simple terms
    >     > everything else
    >     >     > > works
    >     >     > >     > the
    >     >     > >     >     > same so
    >     >     > >     >     >     > the
    >     >     > >     >     >     >     > IDEs still
    >     >     > >     >     >     >     >     > > work for code intelligence.
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > An unspecified 'localId'
    > boolean
    >     > in mxml
    >     >     > > would
    >     >     > >     >     > currently be
    >     >     > >     >     >     > the
    >     >     > >     >     >     >     > same as
    >     >     > >     >     >     >     >     > > false, but could possibly
    > have a
    >     > global
    >     >     > >     > configuration
    >     >     > >     >     >     > default -
    >     >     > >     >     >     >     > not sure
    >     >     > >     >     >     >     >     > > about that, but maybe it
    > could be
    >     > useful.
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > If there is an issue with
    > styling
    >     > on the
    >     >     > > swf
    >     >     > >     > side with
    >     >     > >     >     > valid
    >     >     > >     >     >     >     > multiple ids
    >     >     > >     >     >     >     >     > > vs. html, then I think the
    > swf
    >     > side could
    >     >     > >     > perhaps be
    >     >     > >     >     >     > outlawed in
    >     >     > >     >     >     >     > favour
    >     >     > >     >     >     >     >     > of
    >     >     > >     >     >     >     >     > > best practice for html. Too
    > much?
    >     > :)
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > Anyhow, I am just raising
    > this now
    >     > in
    >     >     > case
    >     >     > >     > anyone else
    >     >     > >     >     > has
    >     >     > >     >     >     > changed
    >     >     > >     >     >     >     > their
    >     >     > >     >     >     >     >     > > thinking after using it
    > as-is for a
    >     >     > while,
    >     >     > > and
    >     >     > >     > before
    >     >     > >     >     > it
    >     >     > >     >     >     > gets too
    >     >     > >     >     >     >     > late to
    >     >     > >     >     >     >     >     > > consider changing it (if it
    > is not
    >     >     > already
    >     >     > > too
    >     >     > >     > late).
    >     >     > >     >     >     >     >     > > If there is some consensus to
    >     > change
    >     >     > this,
    >     >     > > I am
    >     >     > >     > happy
    >     >     > >     >     > to
    >     >     > >     >     >     > work on
    >     >     > >     >     >     >     > it.
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > > 1.
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >
    >     >     > >     >     >     >
    >     >     > >     >     >
    >     >     > >     >
    >     >     > >
    >     >     >
    >     >
    > 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&amp;data=02%7C01%7Caharui%40adobe.com%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&amp;sdata=YmdX8%2Btd1fhFvuzPyMCRuv9y1WecYXrUztaUhEGlFt0%3D&amp;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&amp;data=02%7C01%7Caharui%40adobe.com%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&amp;sdata=o0LQMf6MQEi1wTuqWe0NJ6VgwJu16PnrKJiGeTVnDt0%3D&amp;reserved=0
    >     >     > >     >     >     >     >     > >
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > --
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > Piotr Zarzycki
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >     > Patreon: *
    >     >     > >     >     >     >     >
    >     >     > >     >     >     >
    >     >     > >     >     >
    >     >     > >     >
    >     >     > >
    >     >     >
    >     >
    > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&amp;sdata=wYnMDe%2BeH3hkOXX3bS3CmtHmTzYWTnag4lQPzGU%2ByYs%3D&amp;reserved=0
    >     >     > >     >     >     >     >     > <
    >     >     > >     >     >     >     >
    >     >     > >     >     >     >
    >     >     > >     >     >
    >     >     > >     >
    >     >     > >
    >     >     >
    >     >
    > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&amp;sdata=wYnMDe%2BeH3hkOXX3bS3CmtHmTzYWTnag4lQPzGU%2ByYs%3D&amp;reserved=0
    >     >     > >     >     >     >     > >*
    >     >     > >     >     >     >     >     >
    >     >     > >     >     >     >     >
    >     >     > >     >     >     >     >
    >     >     > >     >     >     >     >
    >     >     > >     >     >     >
    >     >     > >     >     >     >
    >     >     > >     >     >     >
    >     >     > >     >     >
    >     >     > >     >     >
    >     >     > >     >     >
    >     >     > >     >
    >     >     > >     >
    >     >     > >     >
    >     >     > >
    >     >     > >
    >     >     > >
    >     >     >
    >     >     > --
    >     >     > Carlos Rovira
    >     >     >
    >     >
    > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cb3825b6b19064f1cfe6f08d642ecaea7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636769981668065793&amp;sdata=Wcsqb%2FUYANkIUWV7H0Gjo4cPeAtdPHakiBIMHs7TenI%3D&amp;reserved=0
    >     >     >
    >     >
    >     >
    >     >
    >
    >
    >
    

Mime
View raw message