Re: localId vs id

[Hugo Ferreira]

I see now.
Yes, localId it's very important.

Carlos Rovira  escreveu no dia sexta, 24/07/2020
à(s) 09:46:

> localId is very important in Royale also check this:
>
> https://stackoverflow.com/questions/55923924/whats-the-difference-between-id-and-localid-in-apache-royale
>
> El vie., 24 jul. 2020 a las 1:08, Hugo Ferreira ()
> escribió:
>
> > Thanks.
> >
> > Piotr Zarzycki  escreveu no dia quinta,
> > 23/07/2020 à(s) 22:25:
> >
> > > Hi Hugo,
> > >
> > > localId will not be output to HTML after compilation.
> > > id will be translated to as HTML attribute
> > >
> > > 
> > >
> > > Thanks,
> > > Piotr
> > >
> > > On Thu, Jul 23, 2020, 10:59 PM Hugo Ferreira 
> > > wrote:
> > >
> > > > What's the difference between localId and id ?
> > > >
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

Re: localId vs id

[Carlos Rovira]

localId is very important in Royale also check this:
https://stackoverflow.com/questions/55923924/whats-the-difference-between-id-and-localid-in-apache-royale

El vie., 24 jul. 2020 a las 1:08, Hugo Ferreira ()
escribió:

> Thanks.
>
> Piotr Zarzycki  escreveu no dia quinta,
> 23/07/2020 à(s) 22:25:
>
> > Hi Hugo,
> >
> > localId will not be output to HTML after compilation.
> > id will be translated to as HTML attribute
> >
> > 
> >
> > Thanks,
> > Piotr
> >
> > On Thu, Jul 23, 2020, 10:59 PM Hugo Ferreira 
> > wrote:
> >
> > > What's the difference between localId and id ?
> > >
> >
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: localId vs id

[Hugo Ferreira]

Thanks.

Piotr Zarzycki  escreveu no dia quinta,
23/07/2020 à(s) 22:25:

> Hi Hugo,
>
> localId will not be output to HTML after compilation.
> id will be translated to as HTML attribute
>
> 
>
> Thanks,
> Piotr
>
> On Thu, Jul 23, 2020, 10:59 PM Hugo Ferreira 
> wrote:
>
> > What's the difference between localId and id ?
> >
>

Re: localId vs id

[Piotr Zarzycki]

Hi Hugo,

localId will not be output to HTML after compilation.
id will be translated to as HTML attribute



Thanks,
Piotr

On Thu, Jul 23, 2020, 10:59 PM Hugo Ferreira  wrote:

> What's the difference between localId and id ?
>

localId vs id

[Hugo Ferreira]

What's the difference between localId and id ?

Re: Revisiting the old debate: 'localId vs. id'

[Carlos Rovira]

Hi,

after working with id - localId after some days, I start to see what's
comfortable, and what not, and gets more to the core point.

I think that having two of this: id and localId, is strange, since I as a
user, only wants one, and that one be unique in my application. In Flash
this was no brainer and worked ok.
In HTML since all is in the same page, we have this problem, so I think
that the best scenario for me as a user would be:

* get rid of "localId" in favor of only one "id"
* that id works as localId and work *internaly" and not declared in html
* this should be how it works for JS, SWF and if not wrong for the rest of
targets we could add

but how to deal with the need to set up an id in HTML? ok, since this is
for me the side case, I'll vote for an "htmlId" property that could be set
in AS3/MXML and that could be (if I'm not wrong) as a new framework
property (maybe in HTMLElementWrapper?). So users could reference this id
from CSS, in case they needed.

Can't think in a simplest way to deal with this.

The cons of the actual way is that I have all my user code populated with
lots of "localId" and in other places still "id", what seems to something
Royale should take care of, and instead of that users will need to be
worried about something that is one of the things a framework must do for
you. So I think we need to fix that to make it less cumbersome. At last,
that's one of the reasons why people choose frameworks right? :)

Thoughts?

Carlos




El lun., 5 nov. 2018 a las 9:07, Greg Dove () escribió:

> The underlying JS runtimes are highly tolerant of bad code.  We should be
> too, IMO.
>
> I get it. But please let's not make that the marketing slogan :)
>
>
> On Mon, Nov 5, 2018 at 8:39 PM Alex Harui 
> 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"  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
> > 

Re: Revisiting the old debate: 'localId vs. id'

[Greg Dove]

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  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"  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 
> 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"  wrote:
> >
> > Actually I was thinking the 

Re: Revisiting the old debate: 'localId vs. id'

[Alex Harui]

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"  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  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"  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:
>
> 
> [DefaultIdPolicy(policy="external|localOnly")]
> 
>
> -policy parameter is mandatory.
> Basic options are either default to external or 

Re: Revisiting the old debate: 'localId vs. id'

[Greg Dove]

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  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"  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:
>
> 
> [DefaultIdPolicy(policy="external|localOnly")]
> 
>
> -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.
>
> 
> [DocumentIdPolicy(policy="external|localOnly",appliesTo="csv of
> id")]
> 
>
> -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 
> 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])
> > 

Re: Revisiting the old debate: 'localId vs. id'

[Alex Harui]

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"  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:


[DefaultIdPolicy(policy="external|localOnly")]


-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.


[DocumentIdPolicy(policy="external|localOnly",appliesTo="csv of id")]


-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  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"  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
>
>
>
>   

Re: Revisiting the old debate: 'localId vs. id'

[Greg Dove]

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:


[DefaultIdPolicy(policy="external|localOnly")]


-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.


[DocumentIdPolicy(policy="external|localOnly",appliesTo="csv of id")]


-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  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"  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  >
> 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 

Re: Revisiting the old debate: 'localId vs. id'

[Alex Harui]

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"  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 
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
>
>
>
>
>
> 

Re: Revisiting the old debate: 'localId vs. id'

[Greg Dove]

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 
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 ()
> 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:
> >
> > 
> > 
> >
> > 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 

Re: Revisiting the old debate: 'localId vs. id'

[Carlos Rovira]

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 ()
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:
>
> 
> 
>
> 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) 

Re: Revisiting the old debate: 'localId vs. id'

[Alex Harui]

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:




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"  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 

Re: Revisiting the old debate: 'localId vs. id'

[Greg Dove]

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://www.javascriptstuff.com/use-refs-not-ids/#the-solution-refs )

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 

Re: Revisiting the old debate: 'localId vs. id'

[Alex Harui]

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:



private function changeText():void {
sendToServer(myTI.text);
}


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"  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 

Re: Revisiting the old debate: 'localId vs. id'

[Greg Dove]

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://www.javascriptstuff.com/use-refs-not-ids/


On Sat, Nov 3, 2018 at 8:03 AM Alex Harui  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"  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 

Re: Revisiting the old debate: 'localId vs. id'

[Alex Harui]

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"  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  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"  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 

Re: Revisiting the old debate: 'localId vs. id'

[Greg Dove]

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  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"  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 
> 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 

Re: Revisiting the old debate: 'localId vs. id'

[Alex Harui]

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"  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  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 

Re: Revisiting the old debate: 'localId vs. id'

[Greg Dove]

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  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 

Re: Revisiting the old debate: 'localId vs. id'

[Greg Dove]

Hi Harbs, thanks for that feedback.

I do agree that using both localId and id is unlikely and should probably
cause a compiler error if used as it stands currently. Which one wins?
At the moment it is possible and id wins, so yes it would make sense for
the conflict to be a compiler error.

How many people are using legacy IDEs for Royale?
I still use IntelliJ, although I will try VSCode soon.

'I don’t think it’s a good idea to make id default to not creating DOM ids.
That would invalidate CSS for the id.'

How often in practice do you use external id targeting for css styling? I
think mostly it is class (className) based, isn't it?
I'm no expert on CSS styling, but my impression is that the use of ids for
styling in css is minimal (because it is specific).
If it is rare, then presumably it is not a lot of work to switch it on for
specific cases.

But the idea for defaults was more to let the default be configurable:
as-it-is now or opposite.

I've been doing React work for almost 18 months now, and in that experience
use of element level 'id' in jsx (which is propagated to DOM) is extremely
rare. Perhaps my experience is not representative, but it has also
influenced the way I think about this.
And React also has a different paradigm and has a more explicit notion of
local references being separate from 'id' in any case. I'm only mentioning
this to compare, I'm happy to be doing more actionscript/mxml :)




On Fri, Nov 2, 2018 at 10:09 PM Harbs  wrote:

> I tend to like Greg’s suggestion, but I don’t feel strongly on the subject
> one way or another.
>
> I do agree that using both localId and id is unlikely and should probably
> cause a compiler error if used as it stands currently. Which one wins?
>
> I’ve actually never used localId, although I possibly should have. Taking
> VS Code as an example, it seems like there’s no code hinting for localId
> currently, but it is correctly verified when used. How many people are
> using legacy IDEs for Royale?
>
> I don’t think it’s a good idea to make id default to not creating DOM ids.
> That would invalidate CSS for the id.
>
> My $0.02,
> Harbs
>
> > On Nov 2, 2018, at 11:01 AM, Piotr Zarzycki 
> 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:
> >
> >  - Option is ON
> >
> > output will be:
> >
> > 
> >
> > I'm sorry if I misunderstand you completely :)
> >
> > Thanks,
> > Piotr
> >
> > pt., 2 lis 2018 o 08:31 Greg Dove  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

Re: Revisiting the old debate: 'localId vs. id'

[Alex Harui]

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 

Re: Revisiting the old debate: 'localId vs. id'

[Greg Dove]

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



These seem to work well, but the second one is not nice in my IDE, compared
to support for the first one.


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.





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 
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:
>
>  - Option is ON
>
> output will be:
>
> 
>
> I'm sorry if I misunderstand you completely :)
>
> Thanks,
> Piotr
>
> pt., 2 lis 2018 o 08:31 Greg Dove  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

Re: Revisiting the old debate: 'localId vs. id'

[Harbs]

I tend to like Greg’s suggestion, but I don’t feel strongly on the subject one 
way or another.

I do agree that using both localId and id is unlikely and should probably cause 
a compiler error if used as it stands currently. Which one wins?

I’ve actually never used localId, although I possibly should have. Taking VS 
Code as an example, it seems like there’s no code hinting for localId 
currently, but it is correctly verified when used. How many people are using 
legacy IDEs for Royale?

I don’t think it’s a good idea to make id default to not creating DOM ids. That 
would invalidate CSS for the id.

My $0.02,
Harbs

> On Nov 2, 2018, at 11:01 AM, Piotr Zarzycki  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:
> 
>  - Option is ON
> 
> output will be:
> 
> 
> 
> I'm sorry if I misunderstand you completely :)
> 
> Thanks,
> Piotr
> 
> pt., 2 lis 2018 o 08:31 Greg Dove  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
>> 
>> 
>> 
>> 
>> 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 

Re: Revisiting the old debate: 'localId vs. id'

[Piotr Zarzycki]

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:

 - Option is ON

output will be:



I'm sorry if I misunderstand you completely :)

Thanks,
Piotr

pt., 2 lis 2018 o 08:31 Greg Dove  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
>
> 
> 
>
> 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.
>
> http://apache-flex-development.247.n4.nabble.com/FlexJS-MXML-ids-and-classNames-td54361i40.html#a63276
> 2.
>
> http://apache-flex-development.247.n4.nabble.com/FlexJS-MXML-ids-and-classNames-td54361i60.html#a63919
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Revisiting the old debate: 'localId vs. id'

[Greg Dove]

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




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.
http://apache-flex-development.247.n4.nabble.com/FlexJS-MXML-ids-and-classNames-td54361i40.html#a63276
2.
http://apache-flex-development.247.n4.nabble.com/FlexJS-MXML-ids-and-classNames-td54361i60.html#a63919