royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Dove <greg.d...@gmail.com>
Subject Re: Revisiting the old debate: 'localId vs. id'
Date Mon, 05 Nov 2018 08:06:38 GMT
The underlying JS runtimes are highly tolerant of bad code.  We should be
too, IMO.

I get it. But please let's not make that the marketing slogan :)


On Mon, Nov 5, 2018 at 8:39 PM Alex Harui <aharui@adobe.com.invalid> wrote:

> IMO, the benefit of choosing "words" instead of "true/false" "on/off"
> Booleans is that you can invent new allowed values later.  So if some other
> platform does come into play, we can add other allowed values and even a
> comma-separated list of allowed values.    So we can be explicit that we
> have an option that sets IDs on HTMLElements for now and be explicit about
> what we might make it do for other platforms later.  And the doc for the
> new platform can specify whether old options apply or not.
>
> Regarding setting ids on HTMLElement in the first place:  While we often
> talked about Flex as a Framework, lately, I'm thinking of Royale as a
> "workflow".  Royale could turn out to be the most efficient way for people
> to glue together existing chunks of JavaScript.  Or at least, the way that
> folks who program in other languages (Java, C, others?) are familiar with.
> The "framework" aspect of Royale is de-emphasized because Royale supports
> multiple "frameworks" or "component sets".
>
> A "component set" is a bunch of existing JavaScript, and the code the
> application developer writes glues it together.  Good or bad, I think there
> is a ton of existing chunks of JavaScript that use HTMLElement.id and "just
> works".  I am hopeful that Royale will never try to tell folks how write
> their code.  That's why I wouldn't be in favor of switching to
> all-functional-programming, or not allowing some kinds of circular
> dependencies.  Users should be able to "harden" their existing code by
> specifying a strongly-typed API/Typedefs/Externs for the existing chunks of
> code, write some code to glue it to other code, and get it up and running
> faster because our workflow will catch certain errors earlier.
>
> We can/should provide advice and guidance on best practices, but I think
> we'll do better by not requiring that folks conform to those best
> practices.  The underlying JS runtimes are highly tolerant of bad code.  We
> should be too, IMO.
>
> My 2 cents,
> -Alex
>
> On 11/4/18, 11:02 PM, "Greg Dove" <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message