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

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

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

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

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

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

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

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

Re: Dynamic component instantiation and bindings

Are you using the emulation components or the Basic components? We could probably emulate BindingUtils in the emulation components. For Basic, there are beads you can use, like SimpleBinding, ConstantBinding and ChainBinding. I think ChainBinding is closest to BindingUtils.bindProperty. But

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

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

Build failed in Jenkins: royale-typedefs #844

See -- Started by timer Building on master in workspace > git.exe rev-parse

Build failed in Jenkins: royale-asjs_jsonly #1842

See -- [...truncated 431.46 KB...] [java] [java] 4903 bytes written to C:\Program Files

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

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

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

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

RE: Dynamic component instantiation and bindings

Hi Nicolas, There’s an example [1] that seems to at least partially answer your question. Yishay [1] https://github.com/apache/royale-asjs/blob/develop/examples/royale/DataBindingExample_as/src/main/royale/MyInitialView.as#L180 From: Idylog -

Build failed in Jenkins: royale-compiler #538

See -- [...truncated 137.40 KB...] [java] Loading configuration:

Dynamic component instantiation and bindings

Hi all, We make heavy use of BindingUtils bindProperty (mostly) and bindSetter (sometimes) methods. We are a bit confused : is it still possible with Royale to bind explicitly/dynamically (through code) like we did in Flex (as opposed to static binding with curly braces syntax) ? Our use-case

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

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