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 (<aha...@adobe.com.invalid>)
escribió:
> Hi Greg,
>
> I think I've been thinking of it backwards. The compiler had an "id" and
> "effectiveID". Essentlally, explicit references and implicit references.
> The "id" handled databinding and access from script blocks. I don't think
> the compiler had code to prune CSS id selectors that weren't used, but we
> could have added that. The expectation was that "id"s were going to be
> referenced in code and/or CSS and/or bindings, including references to the
> component from outside the file, hence "id" had to be a public API.
>
> EffectiveID was used for implicit references. I think it is used in the
> destination of binding expressions. Such as the Label in:
>
> <mx:DateChooser id="dc" />
> <mx:Label text="{dc.selectedDate}" />
>
> I think effectiveIDs are generated for some other reasons as well. And
> thus they can be private variables and I don't think they generally needed
> to dispatch change events.
>
> I didn't think of localId like "id" since it doesn't affect CSS. So I
> thought it could be like effectiveID, and so when I saw your changes the
> first thing I thought of was all of the vars there were now going to be
> getter/setters, but now that I'm thinking about it more, localId probably
> does have to be more like "id". It has to support databinding and
> referencing from other files. So I agree with you now that if we do
> optimize the generated code to only generate binding events if used in a
> binding expression, we should do it for both id and localID. But also, it
> just occurred to me that we may have to be even smarter and find out if
> folks are setting up bindings or the equivalent in AS code, so I guess we
> should just put that optimization on the back burner for now.
>
> So, I think if you are going to do any more work in this area, it should
> be to get rid of localID and put a per-file option (and optionally, an
> additional compiler option if you want all files in a compilation set) to
> generate different code for "id".
>
> Regarding React and references, I have not played much with React and I
> didn't have time to look at your links today, but it just occurred to me
> that the reason they chose the name React was to switch away from
> procedural programming to functional and/or data-flow programming. That
> was a hot topic around the time that Flex was donated to Apache. Flex and
> Royale are heavily oriented towards procedural programming. It might be
> interesting someday to see what the impact to Royale of introducing a
> functional or data-flow programming workflow would be, but for now, we are
> here to leverage all of the tons of existing procedural code out there,
> from the Flex apps being migrated to Royale, the IDEs that are tuned to
> procedural programming, and the vast amounts of procedural JavaScript out
> there as well.
>
> While there are lots of benefits to functional programming, I'm not clear
> that it is as easy to be successful with functional programming compared to
> procedural programming which is a major factor to our users. Not all of
> our users are trained software engineers and sometimes it is just faster to
> hack something into working. getElementByID and related APIs rely on there
> being a "global scope" and IIRC, these other programming models eliminate
> global scopes. It is, in some ways, the same reason that JavaScript was
> way more popular that Java running in a browser. The ability to just hack
> code until it worked allowed lots of people to ship on time, but the stuff
> they shipped often lacked structure and would fall down later.
> ActionScript, TypeScript, and friends all added structure without being as
> structured as Java. This made it possible to ship much more complex
> applications. I have a saying that anyone can take wood and nails and
> build a dog house, but you need structure to build a skyscraper. The
> global scope and procedural programming puts structure in the instructions
> but does not put structure on access to resources, so it allows you to
> build a skyscraper where every elevator goes from the first floor the top.
> IMO, functional programming at is purest would only let an elevator go from
> one floor to the next.
>
> Anyway, unless we hear from someone else, I think you can start in on
> removing "localID" and adding file and, optionally, project level options.
>
> Thanks,
> -Alex
>
>
>
> On 11/3/18, 1:47 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> Hey Alex,
> Re:
> If you are asking if we should be smart about what code we generate for
> "id" and only add the binding events if the "id" is used in a source
> expression of a binding expression, then yes, we could do that
> optimization
> as well.
>
> Yes I am - but I don't 'get' why you think about localId in a
> different way
> to regular id here. There could be a gap in my understanding. Maybe I
> am
> not seeing the wood for the trees. For me, they are both *exactly* the
> same, except one does not set the id on HtmlElement. So id can be used
> in
> exactly the same way you described in your snippet for localId. In
> which
> case it's also wasteful in exactly the same way, right? If yes, then
> presumably the exact same optimization approach applies to both -
> because
> in the local code (developer's as3, mxml), they are in fact no
> different.... I think?
>
>
> Regarding not using IDs in HTML, IMO, that's not our decision. We
> provide
> the developer choices to set it or not. How should we do it? Since
> you
> and I seem to be thinking this can be controlled at a "whole file"
> level,
> it may be better to get rid of localId and have a per-file directive to
> dictate whether id gets output as "id" and sets the HTMLElement id or
> "_ld"
> and doesn't. Then we wouldn’t have a magic compile-time property that
> the
> IDEs have to learn about.
>
> Sure. I wasn't suggesting 'no option' for the developer, just that I
> don't
> consider it (personally) a common need. Others likely may have a
> different
> view because they do things differently or have encountered situations
> that
> I have not.
> In terms of implementation, yeah I was trying to think of examples
> within
> mxml components where you would actually want to have some with
> localId and
> not others, but nothing sprang to mind. If it's anything where the
> parent
> mxml component is intended to be used with multiple instances, then you
> very likely want it off for all ids, so thus far I also think file
> level
> makes sense.
>
> At some top level views of the application it may be convenient to have
> individual tag instances being switchable, but I think I'd be happy to
> forgo that for a simpler file level implementation.
> If it does remain at instance tag level, then I do think that having a
> boolean attribute switch alongside the regular id attribute to 'turn
> it on
> or off' for DOM setting makes more sense than a separate localId
> string.
> This doesn't break the usefulness of what IDEs already know about 'id'
> although the other new compile-time attribute is 'not known' by the IDE
> unless we can somehow fool the code inspectors.
>
> So yes, I think the file level approach sounds pretty good on the face
> of
> it. I just think this is also really important to get right, because it
> won't be easy to change later, so would be keen to see others'
> thoughts too.
>
> Personally I think my own default for most things will be 'off'
> because I
> think it is rare to actually need the ids at the DOM level.
>
> Regarding React: There must be a way to give a component a name in
> their
> markup so you can reference it from script. What is their way of doing
> that?
>
> Actually most of React considers what we think of as the components
> more
> conceptually as part of the 'rendering', not so much as
> 'instantiations' -
> more like output that derives from properties passed down via the
> parent
> chain, and from local state changes (which triggers 're-render'). Most
> times it's avoidable to do more than follow that approach. But on the
> occasions you need to get a reference from lower down in the
> 'rendering',
> it uses something called 'refs' which are 'kind of' like localId. They
> are
> a way for the 'rendered' component to to pass back a reference of
> themselves to something in the parent chain that rendered them. React
> is
> onto (I think) the 3rd implementation of how this can happen, gradually
> improving things. It used to be passing down a string that was a field
> to
> set on a special object (this.refs) in the parent, which is now
> officially
> deprecated. Then callbacks were used (like the example link I posted
> earlier). The current best practice passes an object that is defined
> on the
> parent using React.createRef() which is populated with a current value
> by
> the child. But again, it is relatively rare to use these. You can see
> an
> example in that link I posted earlier an example of the component doing
> something directly with the HtmlElement (input), using the callback ref
> approach. (
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.javascriptstuff.com%2Fuse-refs-not-ids%2F%23the-solution-refs&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=n2%2Bb6%2FAbwY0oOSkDZE1izBXl6GJQjOdr3akzno4jlsI%3D&reserved=0
> )
>
> In my experience it is rare to reference anything using markup ids,
> using
> the old document.getElementById. For React, most libraries insulate you
> from anything to do with that (possibly wrapping some vanilla js lib to
> make it more React-like) and provide a set of 'props' that you use to
> configure them. If you want to read some possibly biased, but perhaps
> helpful, learning descriptions, you should google 'thinking in react' -
> you can find a concrete example of some of the things I mentioned.
> Styling
> also tends to be different and happen alongside component code, but I
> won't
> go into details.
>
> There's a lot about React/ReactNative that was strange and different
> to me
> (and I'm still learning new things), but I think it forces a number of
> patterns that avoid some of the pitfalls of working with js. Just in
> different ways to what I was familiar with. I actually think learning
> it
> has helped me think about Royale in different ways because it also
> forced
> me to learn about related things like webpack and babel etc as well.
> Enough about React.... hopefully I answered your question somewhere in
> that
>
>
>
>
> On Sat, Nov 3, 2018 at 7:30 PM Alex Harui <aha...@adobe.com.invalid>
> wrote:
>
> > Hi Greg,
> >
> > If you look at all of the code generated for "id", there is a bunch
> of
> > code in there to support databinding. And so, you are correct that
> if
> > someone binds to something with a localId, then you should generate
> the
> > same code as "id".
> >
> > But my point is that localId can be used for reasons other than
> > databinding, in which case you don't need all of that code. Many
> times, it
> > can just be a plain var. As in:
> >
> > <js:TextInput localId="myTi" change="changedText()"/>
> > <fx:Script>
> > private function changeText():void {
> > sendToServer(myTI.text);
> > }
> > </fx:Script>
> >
> > For the snippet above, it is not necessary to handle localId the
> same as
> > "id".
> >
> > If you are asking if we should be smart about what code we generate
> for
> > "id" and only add the binding events if the "id" is used in a source
> > expression of a binding expression, then yes, we could do that
> optimization
> > as well.
> >
> > Regarding not using IDs in HTML, IMO, that's not our decision. We
> provide
> > the developer choices to set it or not. How should we do it? Since
> you
> > and I seem to be thinking this can be controlled at a "whole file"
> level,
> > it may be better to get rid of localId and have a per-file directive
> to
> > dictate whether id gets output as "id" and sets the HTMLElement id
> or "_ld"
> > and doesn't. Then we wouldn’t have a magic compile-time property
> that the
> > IDEs have to learn about.
> >
> > Regarding React: There must be a way to give a component a name in
> their
> > markup so you can reference it from script. What is their way of
> doing
> > that?
> >
> > Thanks,
> > -Alex
> >
> > On 11/2/18, 4:39 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
> >
> > Thanks Alex,
> > For this:
> > I thought there were two problems:
> >
> > A) a compiler warning about binding to something with a localID
> > B) it didn't work in the js-release version.
> >
> > Issues/Expecations
> > --------------------------
> > I did not even look at (A) (or notice it if there is one), and
> yes
> > there
> > was an issue with b - minimization of the getter/setter that
> otherwise
> > would normally prevent issues.
> > The binding issue I observed was that binding from outside the
> > component
> > did not work with localId - but it did work when id was used.
> >
> > So my 'fixes' were based on the assumption that the localId
> feature
> > could
> > be specified as:
> > "Same functionality as 'id' but does not set the HtmlElement id"
> >
> > In other words, I would expect swapping it out simply to change
> the
> > DOM id
> > assignment aspect, and nothing else that already functions
> correctly
> > with
> > 'id'
> > Is this not the original intention?
> >
> > I understand your point about the PAYG aspect and not having a
> bindable
> > getter/setter - but I did not change anything in that
> implementation, I
> > just re-used the original one for 'id' which already does that -
> so it
> > should behave exactly as if 'id' was used I think (I will check
> this,
> > but I
> > don't think there is already an optimization for id?). I did
> this while
> > testing binding issues when swapping id to localId in code,
> compared
> > across
> > flash and js, aiming for identical results.
> >
> > Let me know if the assumption above ("Same functionality as 'id'
> but
> > does
> > not set the HtmlElement id") is wrong, but if it is right, then
> I will
> > try
> > to do what you suggested for *both* localId and id in terms of
> > selective
> > getter/setter output based on source.binding optimizations. Not
> sure at
> > this point how easy this will be, but happy to give it a go
> > (timeframe:during November).
> >
> > Alternatives
> > ---------------
> > In terms of my own use, I would prefer 'not setting' HtmlElement
> id far
> > more routinely than setting it, based on my experience with
> other work
> > over
> > the last 18 months or so. But that's just me (and also my
> experience
> > was
> > using React, not Royale).
> > I just looked at a complex React app in the browser and copied
> out the
> > html
> > in the body tag, and seached for id=" in a few different view
> states.
> > Aside from the top level 'root' tag for the app itself, the rare
> usages
> > were exclusively with 3rd part libs, none of our own code was
> assigning
> > ids. I'm not suggesting this is always typical, because others
> might
> > have
> > quite opposite views. But it is my experience.
> > (I also just googled 'should you use id in react apps' and
> something
> > sort
> > of similar is expressed here[1] - again just for comparison -
> the
> > 'refs'
> > mentioned is the local reference to the element.)
> >
> > In terms of potential changes to the mxml tag implementation
> itself -
> > in
> > the end, I can definitely work with it how it is - although as
> > mentioned
> > earlier, I also agree that it should be an error to have both id
> and
> > localId set with the current approach.
> > And I don't want to belabor the point if everyone decides this is
> > already
> > locked in as-s.
> > But if there is a time to refine or review it, it does seem
> better to
> > do it
> > sooner rather than later. For the IDE aspect, I personally think
> that
> > should factor more in to the decision about how this is
> implemented,
> > but I
> > did not contribute to the original discussion so that's my fault!
> >
> > I'm sorry my posts always end up so long. I will try to keep them
> > shorter.
> > -Greg
> >
> > 1.
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.javascriptstuff.com%2Fuse-refs-not-ids%2F&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=WpGrZvM%2BJNaxKf%2B%2Bpu2au1C%2FFFFNUkt2C9BV4XPduxg%3D&reserved=0
> >
> >
> > On Sat, Nov 3, 2018 at 8:03 AM Alex Harui
> <aha...@adobe.com.invalid>
> > wrote:
> >
> > > Hi Greg,
> > >
> > > I thought there were two problems:
> > >
> > > A) a compiler warning about binding to something with a localID
> > > B) it didn't work in the js-release version.
> > >
> > > The SWF does not rename variables so I would expect it to work
> > whether the
> > > localID is a var or bindable getter/setter due to the default
> > > timing/lifecycle. And I believe it works in js-debug version.
> > >
> > > What converting from var to getter/setter does is add @export
> so that
> > > Google Closure won't rename the localId. So that makes sense,
> but
> > > converting every localId var to a getter/setter is non-optimal
> > because not
> > > all localIds are used in binding expressions, so it would be
> great
> > if you
> > > could optimize it by checking to see if the localId was used
> as the
> > source
> > > (not the destination) in a binding expression. But all of
> this is
> > code
> > > that will solve B, and it occurs to me that the compiler should
> > still be
> > > outputting warnings in A, although we could defer work on that.
> > >
> > > -Alex
> > >
> > > On 11/2/18, 11:50 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
> > >
> > > Alex, sorry if I wasn't clear.
> > >
> > > What I meant was this:
> > > 1) The compiler has always had a notion of IDs and
> > effectiveIDs. IDs
> > > reflect the "id" property in an MXML Instance. You set
> id="foo"
> > and
> > > the
> > > compiler will create a getter/setter with bindable events
> named
> > "foo"
> > > on
> > > the output class.
> > >
> > > I was just matching the above id that for localId in js
> with the
> > belief
> > > that they should work the same locally without any other
> changes
> > (in
> > > actionscript/mxml). My changes should only do that for the
> > localId,
> > > not all
> > > effectiveIds (if not that was not my intention and I will
> fix
> > it).
> > > I assumed this is what was happening in swf because I can
> see the
> > > bindings
> > > working in my side-by-side comparison tests, but it could
> be
> > because of
> > > timing of binding initialization maybe. I will check this.
> > > I had the impression that id and localId were supposed to
> be
> > > functionally
> > > equivalent, with only the HtmlElement setting not
> happening in
> > js.
> > > Maybe
> > > the
> > >
> > > I will think about how to optimize things.
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Nov 3, 2018 at 7:20 AM Alex Harui
> > <aha...@adobe.com.invalid>
> > > wrote:
> > >
> > > > Hi Greg,
> > > >
> > > > I’m not sure what you mean by "match the swf behavior".
> I
> > don't
> > > think the
> > > > SWF output generated bindable getter/setters for every
> > effectiveID,
> > > but it
> > > > might already have the smarts to do that for any
> effectiveID it
> > > finds is
> > > > used in a source expression for databinding. In fact, I
> guess
> > I'm
> > > > surprised that the warning I thought was being generated
> went
> > away
> > > if you
> > > > only changed the JS output. I thought that warning came
> from
> > a check
> > > > elsewhere in code that dictates both SWF and JS compile
> errors.
> > > >
> > > > Getters/setters have function call overhead compared to a
> > plain var,
> > > so
> > > > any time we can skip using them, we have faster smaller
> code.
> > So
> > > Ideally,
> > > > the compiler would only generate getter/setters for "id"
> when
> > it
> > > absolutely
> > > > has to. So if you can, it would be best to try to make
> that
> > change
> > > a bit
> > > > smarter. There is a BindingDataBase that might contain
> useful
> > > information.
> > > >
> > > > I agree that you can assume multiple instances for an
> MXML
> > file in a
> > > SWC,
> > > > but I'm not clear that everyone generates SWCs for their
> MXML
> > files.
> > > >
> > > > Anyway, if we can agree that we could essentially treat
> "id"
> > like we
> > > are
> > > > currently treating "localId" for an entire file, then we
> don't
> > need a
> > > > "localId" compile-time property which would make Royale
> more
> > > compatible
> > > > with existing IDEs.
> > > >
> > > > My 2 cents,
> > > > -Alex
> > > >
> > > > On 11/2/18, 10:58 AM, "Greg Dove" <greg.d...@gmail.com>
> wrote:
> > > >
> > > > Hi Alex, Thanks for the comprehensive info!
> > > >
> > > > Just a few selective comments:
> > > >
> > > > 'Greg's changes appear to generate bindable
> getter/setters
> > for
> > > all
> > > > localIDs. This will work for now, but IMO, isn't as
> PAYG
> > as it
> > > could
> > > > be.'
> > > >
> > > > Sorry I was not clear in my understanding if this was
> > > intentionally
> > > > omitted. I thought that localId was the same as id,
> but
> > just
> > > avoids the
> > > > HTMLElement id setting. So I expected switching id to
> > localId to
> > > > continue
> > > > to work the same but fix the browser console
> duplicate id
> > > alerts. That
> > > > is
> > > > what I was addressing here. But I think my changes
> in js
> > match
> > > the swf
> > > > behavior now?
> > > >
> > > > I'm not proposing anything added to UIBase, just a
> > different way
> > > to
> > > > implement the compile-time feature.
> > > >
> > > > 'One question I have is whether the developer of an
> MXML
> > > Component
> > > > "knows"
> > > > that the component is intended to have multiple
> instances
> > or
> > > not. If
> > > > not,
> > > > the problem gets harder, as the generated output
> need to
> > be told
> > > > whether to
> > > > set the HTMLElement id or not. If the developer
> "knows",
> > we
> > > could find
> > > > some way to tell the compiler to generate all "Id"
> as what
> > we are
> > > > currently
> > > > generating for "localId". '
> > > >
> > > > If the MXML Component is part of a swc, it is safest
> to
> > assume
> > > that it
> > > > is
> > > > possible to have multiple instances I think. But not
> > really known
> > > > (although
> > > > some component types can be assumed to be likely).
> > > >
> > > > 'Thinking about it now, I can't think of why, in a
> single
> > MXML
> > > file,
> > > > you
> > > > would need to sometimes set "id" and other times set
> > "localId".
> > > I
> > > > think
> > > > either you want all ids in a file to not set the
> > HTMLElement ids
> > > or
> > > > not. '
> > > >
> > > > This seems true also, thinking about it - that's good
> > insight.
> > > >
> > > >
> > > >
> > > > On Sat, Nov 3, 2018 at 6:25 AM Alex Harui
> > > <aha...@adobe.com.invalid>
> > > > wrote:
> > > >
> > > > > Greg's suggestion is valid. And there could
> certainly
> > be a
> > > better
> > > > > solution than "localID". But maybe we need
> agreement on
> > the
> > > problem
> > > > space
> > > > > first.
> > > > >
> > > > > IMO, the problem of multiple IDs is rare. Can we
> agree
> > on
> > > that? My
> > > > guess
> > > > > is that 90% of .MXML files never have more than one
> > instance
> > > of them
> > > > on
> > > > > screen at a time.
> > > > >
> > > > > So, if we can agree on that, then we want to apply
> PAYG
> > to the
> > > > solution.
> > > > > We want folks to be able to create an MXML file
> for the
> > 90%
> > > case,
> > > > use IDs,
> > > > > use CSS and third-party libraries that call
> > getElementById and
> > > > things "just
> > > > > work". Hopefully, we can agree that it is ok for
> more
> > work to
> > > be
> > > > required
> > > > > by the developer and more code to be generated and
> run
> > to have
> > > > multiple
> > > > > instances of an MXML file on screen.
> > > > >
> > > > > Technically there are two sections of code that
> factor
> > into
> > > this:
> > > > >
> > > > > 1) The compiler has always had a notion of IDs and
> > > effectiveIDs. IDs
> > > > > reflect the "id" property in an MXML Instance.
> You set
> > > id="foo" and
> > > > the
> > > > > compiler will create a getter/setter with bindable
> > events named
> > > > "foo" on
> > > > > the output class. This is super important in
> Flash since
> > > classes are
> > > > > sealed (not dynamic) and so you must declare slots
> to
> > hold
> > > > references to
> > > > > instances on the output class. But there are cases
> where
> > an
> > > instance
> > > > is
> > > > > referenced by some other piece of the MXML file
> but the
> > > developer
> > > > did not
> > > > > specify an id. Binding expressions can do that.
> I think
> > > there are
> > > > other
> > > > > scenarios, but I can't think of them right now.
> In these
> > > cases the
> > > > > compiler generates an effectiveID and a simple
> private
> > var on
> > > the
> > > > output
> > > > > class for every effectiveID. In the MXML output,
> the
> > > effectiveID is
> > > > given
> > > > > the property name "_id".
> > > > >
> > > > > 2) The framework code has UIBase with an "id"
> property
> > setter
> > > that
> > > > sets
> > > > > the id on the HTMLElement. In addition, the
> > > MXMLDataIntepreter has
> > > > logic
> > > > > that tests if a property being set on an instance
> is
> > named
> > > "id" or
> > > > "_id".
> > > > > If "id", additional logic sets the slot on the
> document
> > and
> > > sets the
> > > > "id"
> > > > > property on the instance to set the HTMLElement's
> id. If
> > > "_id", it
> > > > only
> > > > > sets the slot on the document, but not the
> instance,
> > since it
> > > could
> > > > assume
> > > > > that no other code should care that the instance
> has its
> > id
> > > set (and
> > > > thus,
> > > > > for browser versions, whether the HTMLElement id
> is set).
> > > > >
> > > > > "localId" is a "compile-time property". It is one
> of a
> > few
> > > > properties
> > > > > that don't actually exist on the instance's
> ActionScript
> > > > implementation.
> > > > > Other examples are "includeIn" and "excludeFrom"
> for
> > states.
> > > So, the
> > > > > localId" doesn't introduce a new problem for IDEs,
> they
> > all
> > > had to
> > > > deal
> > > > > with includeIn/excludeFrom already, but it is true
> that
> > IDEs
> > > still
> > > > need to
> > > > > learn about it.
> > > > >
> > > > > The localID implementation before Greg's changes
> > leveraged the
> > > > effectiveID
> > > > > aspect of all of this code. It did not generate
> bindable
> > > > getter/setters
> > > > > "just in case" the element with the localID was
> used in
> > > Bindings.
> > > > It did
> > > > > not set the instance's id which would run code to
> set the
> > > > HTMLElement's
> > > > > id. However, if the element with a localId was
> used in a
> > > binding
> > > > > expression then you would get a warning.
> > > > >
> > > > > Greg's changes appear to generate bindable
> > getter/setters for
> > > all
> > > > > localIDs. This will work for now, but IMO, isn't
> as
> > PAYG as it
> > > > could be.
> > > > > Ideally, the compiler would find out if the
> localID is
> > used in
> > > the
> > > > source
> > > > > expression of a binding expression and only then
> > generate the
> > > > bindable
> > > > > getter/setter. FWIW, another possible fix would
> be to
> > > suppress the
> > > > > warning, but there might be a timing issue around
> > effectveIDs
> > > used in
> > > > > states.
> > > > >
> > > > > IMO, any proposal to add another actual property
> on every
> > > instance of
> > > > > UIBase "just-in-case" someone is going to use
> multiple
> > > instances of
> > > > an MXML
> > > > > file doesn't seem PAYG to me. This is why we
> originally
> > chose
> > > the
> > > > current
> > > > > implementation. Any proposal that makes the
> setter for
> > "id"
> > > do an
> > > > extra
> > > > > check "just-in-case" the instance is used in
> multiple
> > > instances of
> > > > an MXML
> > > > > file doesn't seem PAYG to me either. We could
> change the
> > > meaning
> > > > of, or
> > > > > name of "localID", but then it is still a
> compile-time
> > > property that
> > > > IDE's
> > > > > have to handle.
> > > > >
> > > > > One question I have is whether the developer of an
> MXML
> > > Component
> > > > "knows"
> > > > > that the component is intended to have multiple
> > instances or
> > > not.
> > > > If not,
> > > > > the problem gets harder, as the generated output
> need to
> > be
> > > told
> > > > whether to
> > > > > set the HTMLElement id or not. If the developer
> > "knows", we
> > > could
> > > > find
> > > > > some way to tell the compiler to generate all "Id"
> as
> > what we
> > > are
> > > > currently
> > > > > generating for "localId". Thinking about it now,
> I
> > can't
> > > think of
> > > > why, in
> > > > > a single MXML file, you would need to sometimes
> set "id"
> > and
> > > other
> > > > times
> > > > > set "localId". I think either you want all ids
> in a
> > file to
> > > not
> > > > set the
> > > > > HTMLElement ids or not.
> > > > >
> > > > > And if that's true, then we can think of ideas to
> treat
> > the id
> > > > property in
> > > > > a file instead of a per-MXML-tag way. One way to
> do
> > that is a
> > > > compiler
> > > > > option, but then you would have to compile that
> MXML file
> > > separately
> > > > (or
> > > > > with other multi-instance MXML files). Another is
> some
> > sort of
> > > > > "directive", maybe metadata or a special comment.
> In AS
> > > files, we
> > > > already
> > > > > have special metadata and comments for compiler
> > directives.
> > > > >
> > > > > Of course, I could be wrong...
> > > > > -Alex
> > > > >
> > > > > On 11/2/18, 10:13 AM, "Greg Dove" <
> greg.d...@gmail.com>
> > wrote:
> > > > >
> > > > > Hi Piotr,
> > > > >
> > > > > Thanks for your interest in this. Just to be
> clear, I
> > > don't want
> > > > to
> > > > > claim
> > > > > that this is 'my idea' - it's more a re-visit
> of
> > things
> > > that
> > > > have been
> > > > > discussed before, and is probably very similar
> to
> > some
> > > options
> > > > that
> > > > > were
> > > > > decided against previously. I just wondered if
> > anyone had
> > > > changed their
> > > > > mind about this. I'm only raising it after some
> > initial
> > > use of
> > > > localId
> > > > > and
> > > > > just my using reaction to that experience
> (possibly
> > heavily
> > > > influenced
> > > > > by
> > > > > the red messages I see in Intellij).
> > > > >
> > > > > At the moment we have
> > > > >
> > > > > <instance id="setDOMid" />
> > > > > <instance localId="doNotSetDOMId" />
> > > > > These seem to work well, but the second one is
> not
> > nice in
> > > my
> > > > IDE,
> > > > > compared
> > > > > to support for the first one.
> > > > >
> > > > > <instance id="regularId" localId="localId" />
> > > > > This probably should be an error for the
> current
> > > implementation,
> > > > as
> > > > > Harbs
> > > > > has pointed out. But at the moment it is
> possible
> > and 'id'
> > > wins.
> > > > >
> > > > > What I am suggesting is that we reconsider to
> have
> > only
> > > one 'id'
> > > > and a
> > > > > second boolean flag to 'switch' it to
> localOnly or
> > not.
> > > This flag
> > > > > could be
> > > > > 'localId' or 'localIdOnly', whatever seems
> best - I
> > will
> > > use
> > > > > 'localIdOnly' below to differentiate from the
> above.
> > > > >
> > > > > <Instance id="myLocalOnlyId"
> localIdOnly="true" />
> > > > > <Instance id="myLegacyId" localIdOnly ="false"
> />
> > > > > <Instance id="myId" />
> > > > >
> > > > > By default 'localIdOnly' would be false when
> it is
> > not
> > > > specified, so
> > > > > the
> > > > > same behaviour as it is now - the 3rd case
> above.
> > > > > But I think it might be helpful to have the
> option
> > to have
> > > a
> > > > global
> > > > > config
> > > > > for this so you could do a global default as a
> > compiler
> > > setting
> > > > to
> > > > > set it
> > > > > to true by default - e.g. like 'ignore
> coercion' is
> > set up
> > > iirc.
> > > > This
> > > > > might
> > > > > suit some people who prefer to 'start with
> things
> > off and
> > > switch
> > > > them
> > > > > on
> > > > > only if needed'.
> > > > > localIdOnly in the examples above is a compile
> time
> > > mxml-only tag
> > > > > setting
> > > > > and is not propagated to the instantiated
> > components, so
> > > it is
> > > > not a
> > > > > real
> > > > > value assignment to the instance and does not
> exist
> > as a
> > > > property on
> > > > > the
> > > > > instances.
> > > > >
> > > > > What this could mean: All IDEs still see the
> id as
> > 'normal'
> > > > legacy use
> > > > > -
> > > > > for code completion, bindings, script block
> > references
> > > etc. The
> > > > new
> > > > > 'unknown' localIdOnly boolean attribute is
> the only
> > thing
> > > that
> > > > IDEs
> > > > > would
> > > > > need to special-case, which I think should be
> easier
> > than
> > > the
> > > > localId
> > > > > string variation (I assume).
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Nov 2, 2018 at 10:01 PM Piotr Zarzycki
> <
> > > > > piotrzarzyck...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Greg,
> > > > > >
> > > > > > I'm really happy that you are helping Carlos
> with
> > that!
> > > He may
> > > > move
> > > > > forward
> > > > > > much faster. I just have question to
> following:
> > > > > >
> > > > > > "-My understanding is that best practice is
> to
> > avoid
> > > multiple
> > > > > identical ids
> > > > > > in the browser, irrespective of whether the
> > browser is
> > > > forgiving of
> > > > > that or
> > > > > > not. If so, it might be good to have at
> least an
> > option
> > > to set
> > > > the
> > > > > default
> > > > > > implementation to support 'best practice'
> (DOM ids
> > 'off'
> > > by
> > > > default,
> > > > > 'on'
> > > > > > explicitly, to avoid 'duplicate ids by
> accident').
> > Maybe
> > > some
> > > > sort of
> > > > > > import wizard for a legacy flex project
> could do
> > > something
> > > > like this
> > > > > in an
> > > > > > IDE by default though. But it could be a
> compiler
> > config
> > > thing
> > > > too
> > > > > > perhaps."
> > > > > >
> > > > > > Does your idea is saying that if I have some
> Flex
> > app or
> > > even
> > > > write
> > > > > some on
> > > > > > my own setting that option to ON - change
> the way
> > how
> > > things
> > > > are
> > > > > > outputting after compilation ? Do you mean
> that:
> > > > > >
> > > > > > <Button id="myid" /> - Option is ON
> > > > > >
> > > > > > output will be:
> > > > > >
> > > > > > <Button localId="myid" />
> > > > > >
> > > > > > I'm sorry if I misunderstand you completely
> :)
> > > > > >
> > > > > > Thanks,
> > > > > > Piotr
> > > > > >
> > > > > > pt., 2 lis 2018 o 08:31 Greg Dove <
> > greg.d...@gmail.com>
> > > > napisał(a):
> > > > > >
> > > > > > > In collaboration with Carlos, I worked on a
> > compiler
> > > fix for
> > > > some
> > > > > issues
> > > > > > > identified with localId in the javascript
> > output. I
> > > pushed
> > > > that a
> > > > > short
> > > > > > > while ago. This fixes
> > > > > > > -binding into the localId (in my local test
> > cases) and
> > > > > > > -some occasional issues with referencing
> the
> > instance
> > > from
> > > > within
> > > > > script
> > > > > > > blocks in release (minified) code.
> > > > > > > Or at least, it does so for the cases I
> have been
> > > testing. If
> > > > > anyone else
> > > > > > > sees remaining issues with this feature
> that
> > need more
> > > > attention,
> > > > > please
> > > > > > > let me know.
> > > > > > >
> > > > > > > Now on to the 'subject' :
> > > > > > > As part of 'getting familiar' with this I
> went
> > back to
> > > read
> > > > old
> > > > > threads
> > > > > > > about 'id v.s localId'.
> > > > > > > I *think* these [1] [2] were the main
> ones, but
> > maybe I
> > > > missed
> > > > > some other
> > > > > > > discussions.
> > > > > > >
> > > > > > > After reading these, I wondered if anyone
> had
> > changed
> > > their
> > > > views
> > > > > about
> > > > > > the
> > > > > > > implementation as it is, after having used
> it
> > for a
> > > while.
> > > > > > >
> > > > > > > It may be too late to change things, but
> here
> > are my
> > > quick
> > > > > thoughts about
> > > > > > > this:
> > > > > > > -My understanding is that best practice is
> to
> > avoid
> > > multiple
> > > > > identical
> > > > > > ids
> > > > > > > in the browser, irrespective of whether the
> > browser is
> > > > forgiving
> > > > > of that
> > > > > > or
> > > > > > > not. If so, it might be good to have at
> least an
> > > option to
> > > > set the
> > > > > > default
> > > > > > > implementation to support 'best practice'
> (DOM
> > ids
> > > 'off' by
> > > > > default, 'on'
> > > > > > > explicitly, to avoid 'duplicate ids by
> > accident').
> > > Maybe
> > > > some sort
> > > > > of
> > > > > > > import wizard for a legacy flex project
> could do
> > > something
> > > > like
> > > > > this in
> > > > > > an
> > > > > > > IDE by default though. But it could be a
> compiler
> > > config
> > > > thing too
> > > > > > perhaps.
> > > > > > >
> > > > > > > -I can't think of a scenario where I would
> want
> > to set
> > > both
> > > > id and
> > > > > > localId
> > > > > > > at the same time or what doing so would
> mean.
> > Either
> > > you
> > > > want to
> > > > > set the
> > > > > > > DOM id or you don't, in which case missing
> id and
> > > defined
> > > > localId
> > > > > is more
> > > > > > > like a boolean for not setting DOM id (the
> > > implementation is
> > > > not,
> > > > > but to
> > > > > > me
> > > > > > > it seems that it could -maybe should- be).
> Maybe
> > I am
> > > missing
> > > > > something
> > > > > > > here.
> > > > > > >
> > > > > > > -'id' is the basis for code
> > completion/intelligence in
> > > legacy
> > > > > IDEs. Using
> > > > > > > 'localId' means this does not work in the
> legacy
> > IDEs
> > > and
> > > > newer
> > > > > IDEs need
> > > > > > > to add custom support for it. Anything that
> > keeps 'id'
> > > as the
> > > > > primary
> > > > > > local
> > > > > > > identifier seems like the best way to get
> more
> > life
> > > out of
> > > > legacy
> > > > > IDEs.
> > > > > > >
> > > > > > > So to me, the simplest option seems to be
> more
> > along
> > > the
> > > > lines of
> > > > > > >
> > > > > > > <Instance id="myLocalOnlyId"
> localId="true" />
> > > > > > > <Instance id="myLegacyId" localId="false"
> />
> > > > > > >
> > > > > > > Semantically it is probably better as
> > 'localIdOnly'
> > > for the
> > > > boolean
> > > > > > > setting, but 'localId' is shorter (which is
> > perhaps
> > > better).
> > > > > > >
> > > > > > > In this case, you get more mileage from
> older
> > IDEs,
> > > and a
> > > > simpler
> > > > > > > implementation for updating IDEs to handle
> the
> > extra
> > > > mxml-only
> > > > > boolean
> > > > > > > setting. In simple terms everything else
> works
> > the
> > > same so
> > > > the
> > > > > IDEs still
> > > > > > > work for code intelligence.
> > > > > > >
> > > > > > > An unspecified 'localId' boolean in mxml
> would
> > > currently be
> > > > the
> > > > > same as
> > > > > > > false, but could possibly have a global
> > configuration
> > > > default -
> > > > > not sure
> > > > > > > about that, but maybe it could be useful.
> > > > > > >
> > > > > > > If there is an issue with styling on the
> swf
> > side with
> > > valid
> > > > > multiple ids
> > > > > > > vs. html, then I think the swf side could
> > perhaps be
> > > > outlawed in
> > > > > favour
> > > > > > of
> > > > > > > best practice for html. Too much? :)
> > > > > > >
> > > > > > > Anyhow, I am just raising this now in case
> > anyone else
> > > has
> > > > changed
> > > > > their
> > > > > > > thinking after using it as-is for a while,
> and
> > before
> > > it
> > > > gets too
> > > > > late to
> > > > > > > consider changing it (if it is not already
> too
> > late).
> > > > > > > If there is some consensus to change this,
> I am
> > happy
> > > to
> > > > work on
> > > > > it.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 1.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.2333347.n4.nabble.com%2FFlexJS-MXML-ids-and-classNames-td54361i40.html%23a63276&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=7xB6qx%2F6M8L%2FNneQg2xnr999g7BFlFHZjbtm86v%2Bj1w%3D&reserved=0
> > > > > > > 2.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.2333347.n4.nabble.com%2FFlexJS-MXML-ids-and-classNames-td54361i60.html%23a63919&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=NhHoBRQX5b6GcypvyXgIm%2F7obQZZS%2BwLNHg3moD0JJM%3D&reserved=0
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Piotr Zarzycki
> > > > > >
> > > > > > Patreon: *
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=Qx1%2FIQYZuTA8uGDDtiFPrN1Kv5sl%2FYq25VKKSM9X9TE%3D&reserved=0
> > > > > > <
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca2ae588ad66d44036ed608d64168ee90%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636768316293810918&sdata=Qx1%2FIQYZuTA8uGDDtiFPrN1Kv5sl%2FYq25VKKSM9X9TE%3D&reserved=0
> > > > > >*
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
