You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by "Sergey Egorov (JIRA)" <ji...@apache.org> on 2012/04/23 09:24:40 UTC
[jira] [Created] (FLEX-51) Please check support for ExactValue
initializer
Sergey Egorov created FLEX-51:
---------------------------------
Summary: Please check support for ExactValue initializer
Key: FLEX-51
URL: https://issues.apache.org/jira/browse/FLEX-51
Project: Apache Flex
Issue Type: Improvement
Reporter: Sergey Egorov
Assignee: Bertrand Delacretaz
Priority: Minor
Attachments: exactValue.patch
I've done my own improvement for MXML to support any values for property initializer WITHOUT bindings, for example:
Was:
<TextField xmlns="flash.text.*" autoSize="{TextFieldAutoSize.CENTER}" />
is generated into:
private function _MyOwnFlexFrameworkTest_TextField1_i() : flash.text.TextField
{
var temp : flash.text.TextField = new flash.text.TextField();
_MyOwnFlexFrameworkTest_TextField1 = temp;
mx.binding.BindingManager.executeBindings(this, "_MyOwnFlexFrameworkTest_TextField1", _MyOwnFlexFrameworkTest_TextField1);
return temp;
}
// binding mgmt
private function _MyOwnFlexFrameworkTest_bindingsSetup():Array
{
var result:Array = [];
result[0] = new mx.binding.Binding(this,
function():String
{
var result:* = (TextFieldAutoSize.CENTER);
return (result == undefined ? null : String(result));
},
null,
"_MyOwnFlexFrameworkTest_TextField1.autoSize"
);
return result;
}
now:
<TextField xmlns="flash.text.*" autoSize="${TextFieldAutoSize.CENTER}" />
give us such result:
private function _MyOwnFlexFrameworkTest_TextField1_i() : flash.text.TextField
{
var temp : flash.text.TextField = new flash.text.TextField();
temp.autoSize = TextFieldAutoSize.CENTER;
_MyOwnFlexFrameworkTest_TextField1 = temp;
mx.binding.BindingManager.executeBindings(this, "_MyOwnFlexFrameworkTest_TextField1", _MyOwnFlexFrameworkTest_TextField1);
return temp;
}
this implementation is similar to twoWay bindings and written in the same way.
here is the patch:
http://dl.dropbox.com/u/18819203/exactValue.patch
btw, sorry for my English, I'm Russian.
Thanks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by "Sergey Egorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FLEX-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Egorov updated FLEX-51:
------------------------------
Attachment: exactValue.patch
implementation
> Please check support for ExactValue initializer
> -----------------------------------------------
>
> Key: FLEX-51
> URL: https://issues.apache.org/jira/browse/FLEX-51
> Project: Apache Flex
> Issue Type: Improvement
> Reporter: Sergey Egorov
> Assignee: Bertrand Delacretaz
> Priority: Minor
> Attachments: exactValue.patch
>
>
> I've done my own improvement for MXML to support any values for property initializer WITHOUT bindings, for example:
> Was:
> <TextField xmlns="flash.text.*" autoSize="{TextFieldAutoSize.CENTER}" />
> is generated into:
> private function _MyOwnFlexFrameworkTest_TextField1_i() : flash.text.TextField
> {
> var temp : flash.text.TextField = new flash.text.TextField();
> _MyOwnFlexFrameworkTest_TextField1 = temp;
> mx.binding.BindingManager.executeBindings(this, "_MyOwnFlexFrameworkTest_TextField1", _MyOwnFlexFrameworkTest_TextField1);
> return temp;
> }
> // binding mgmt
> private function _MyOwnFlexFrameworkTest_bindingsSetup():Array
> {
> var result:Array = [];
> result[0] = new mx.binding.Binding(this,
> function():String
> {
> var result:* = (TextFieldAutoSize.CENTER);
> return (result == undefined ? null : String(result));
> },
> null,
> "_MyOwnFlexFrameworkTest_TextField1.autoSize"
> );
> return result;
> }
> now:
> <TextField xmlns="flash.text.*" autoSize="${TextFieldAutoSize.CENTER}" />
> give us such result:
> private function _MyOwnFlexFrameworkTest_TextField1_i() : flash.text.TextField
> {
> var temp : flash.text.TextField = new flash.text.TextField();
> temp.autoSize = TextFieldAutoSize.CENTER;
> _MyOwnFlexFrameworkTest_TextField1 = temp;
> mx.binding.BindingManager.executeBindings(this, "_MyOwnFlexFrameworkTest_TextField1", _MyOwnFlexFrameworkTest_TextField1);
> return temp;
> }
> this implementation is similar to twoWay bindings and written in the same way.
> here is the patch:
> http://dl.dropbox.com/u/18819203/exactValue.patch
> btw, sorry for my English, I'm Russian.
> Thanks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Left Right <ol...@gmail.com>.
I think I can explain the undefined order.
The attributes are stored in the hash-map-like structure, which is
unordered, so you cannot build on some attributes' values being assigned
before the others. In languages which allow you to control how bindings
are executed (for example, in Lisp or Miranda) you have special forms for
bindings that allow referencing other bindings and others that don't. Forms
that ensure that all bindings wait until values are created are more
complex to implement, usually you try to avoid them in your program. For
example, in Common Lisp these are:
(let () ...) and (let* () ...)
(flet () ...) and (labels () ...)
to illustrate it further:
(let ((a 21) (b (* a 2))) (princ b)) ; error variable 'a' is unbound
(let* ((a 21) (b (* a 2))) (princ b)); 42
MXML takes away the ability to define the order in which bindings are
initialized (because using XML for source code templates is inherently a
bad idea).
So, MXML tries to act like the (let* ...) binding, but this is often
redundant. The problem with implementing a simple (let ...) binding is that
MXML is very primitive and it cannot infer that the binding creates
circular- or cross-references.
There is another problem - it is very common in AS to introduce side
effects in setters, so even if you didn't create circular or
cross-references, the side effects may bite you in the back, especially so
when you don't know in what order they are executed.
Yet another problem with this approach is that the generated code
is undetermined. That is, if you will try to generate hashes from your
compiled application, the person compiling your application will not get
the same result as you did. Or will not always get it. You may not be sure
that the version sent to QA is the same as you have in your development
environment. Well, in other words - this is kind of a brainfart of an MXML
inventor... it would be great if it was possible to solve it with a simple
patch like this, but the problem is more generic than that. We actually
need to change the MXML behavior in the way it is deterministic, or, at
least, is deterministic on demand, even if this means longer compilation
times.
Best.
Oleg
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Pepe <pe...@gmail.com>.
Hello
I'm interested in adding a new MXML rule. And ah, why don't we extend the idea?
I mean, At compile time, is it possible to load jar files which
include external MXML rules?
thanks
Shigeru Nakagaki
2012/4/25 Left Right <ol...@gmail.com>:
>>
>>
>> Is there a bug# for that?
>>
>> I think I did file a bug for it about 2-3 years ago, but I can't promise
> I'll find it. In any way, it was mentioned in another bug that I filed on
> binding constants - which was resoled as "won't fix" or "cannot fix".
> Besides, it's really difficult to create a reproducible example of
> something which is, by definition inconsistent. But I can imagine that you
> create something like:
>
> <foo id="bar" a0="{bar.a1}"
> a1="{bar.a2}" a2="{bar.a3}" a3="{bar.a4}" a4="{bar.a5}" ... an="{bar.an
> +1}" an+1="value"/>
> you will have a better chance to get it.
>
> Best.
>
> Oleg
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Left Right <ol...@gmail.com>.
>
>
> Is there a bug# for that?
>
> I think I did file a bug for it about 2-3 years ago, but I can't promise
I'll find it. In any way, it was mentioned in another bug that I filed on
binding constants - which was resoled as "won't fix" or "cannot fix".
Besides, it's really difficult to create a reproducible example of
something which is, by definition inconsistent. But I can imagine that you
create something like:
<foo id="bar" a0="{bar.a1}"
a1="{bar.a2}" a2="{bar.a3}" a3="{bar.a4}" a4="{bar.a5}" ... an="{bar.an
+1}" an+1="value"/>
you will have a better chance to get it.
Best.
Oleg
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Alex Harui <ah...@adobe.com>.
On 4/24/12 11:28 AM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
>> I consider the current binding system to be consistent.
> No, it's not. It is possible to get the same code compiled with all the
> same settings and get different behaviors.
Is there a bug# for that?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Left Right <ol...@gmail.com>.
> I consider the current binding system to be consistent.
No, it's not. It is possible to get the same code compiled with all the
same settings and get different behaviors. This is exactly what consistency
is not.
What I would be looking for is that the non-binding attributes were the
defaults, that MXML promised a deterministic order of binding, and that the
present model be fixed to actually do what it
looks-like-it-does-but-not-really. I.e. employ the mechanism that ensures
that all bindings were assigned values provided in attributes, and that the
later be made clearly distinct and alert users on potential overhead.
Best.
Oleg
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Alex Harui <ah...@adobe.com>.
On 4/24/12 10:47 AM, "Omar Gonzalez" <om...@gmail.com> wrote:
>>
>> Optimizing for read-once variable expressions just sounds dangerous to me.
>> I would not want to bake that into the compiler and invite people into a
>> trap.
>>
>
> All I'm saying is that if we're going to turn it down it should be on
> technical merit, or lack thereof, as opposed to whether it invites
> something bad, because there's lots of bad things that can be done and if
> we use that as criteria for changes then we'll never make any changes.
I think "technical merit" includes whether a feature has consistent
behavior. I consider the current binding system to be consistent. You can
mis-use it, but for any given expression, it will evaluate correctly. This
proposal, if it includes expressions with variables, introduces timing
dependencies. I think that is a technical flaw.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Omar Gonzalez <om...@gmail.com>.
>
> Optimizing for read-once variable expressions just sounds dangerous to me.
> I would not want to bake that into the compiler and invite people into a
> trap.
>
> One way to find out how such a thing would work in the real world without
> changing the compiler is to create a custom helper class that does
> essentially the same thing. Folks can then try out using a SetOnceBinding
> class and we'll see how often folks get burned by it. I was looking into
> other specific binding helper classes to optimize bindings for
> itemrenderers
> and skins when 11/11 hit.
I think that if we're going to not accept this change proposal I think it
has to be for better reasons than this. If we're worried about dangerous
code that might invite people into traps then let's just kill off bindings
altogether, I mean there are a tons of traps in the bindings world if you
don't use them right. While we're at it, we should also kill off
lambdas/anonymous functions, those are also a trap if used incorrectly.
Also, too many interfaces can get confusing, lets kill those too they
invite too many traps... See where I'm going with this? I think its a
mistake to not want to accept changes because you're trying to save people
from their own code. We will never save people from their own code, so
things like bindings, while useful, will always be misused by someone that
just doesn't have the experience or know better, that doesn't mean it
shouldn't exist in the language/framework.
All I'm saying is that if we're going to turn it down it should be on
technical merit, or lack thereof, as opposed to whether it invites
something bad, because there's lots of bad things that can be done and if
we use that as criteria for changes then we'll never make any changes.
-omar
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Omar Gonzalez <om...@gmail.com>.
On Tue, Apr 24, 2012 at 10:28 AM, Gordon Smith <go...@adobe.com> wrote:
> Speaking as the person who has written the most complete spec for MXML (at
> far as I know) -- although I'm not currently as an active contributor to
> Apache Flex -- this use of $ in the language strikes me as rather
> arbitrary. Other MXML compiler directives start with @, such as @Embed,
> @Resource, and @{...}. BTW, I see the latter as a poor choice; it should
> have been something like @TwoWay{...} for consistency with the others.
>
> I suggest @Once.
>
> - Gordon
I think the @Once{} syntax looks much more appealing than ${}, as Gordon
states it looks a lot more consistent with other directives and it also
expresses its intent much more clearly. I like this proposal as an addition
to the framework. I would expect @Once to set the value one time during
instantiation of the object with the directive, waiting for first non-null
just doesn't sound like a good thing.
-omar
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> it should have been something like @TwoWay{...} for consistency with the others.
If this feature is added perhaps we should consider adding support for "@TwoWay" and add a warning for "@{}" as deprecated down the track?
> I suggest @Once.
Good suggestion. Makes the intent in the code 100% clear even to people unaware of this feature.
Thanks,
Justin
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Is it possible to support a constant directive using this patch immediately
> while we work out the details for the Once directive?
You can take the patch now and apply it to your environment. As the change only effects how the binding AS code is created and not a change to the SDK code base there no issue with /which version of the SDK you are deploying/RSLs etc etc
> Or is that already happening with constants?
It's not currently happening.
Thanks,
Justin
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by jude <fl...@gmail.com>.
Is it possible to support a constant directive using this patch immediately
while we work out the details for the Once directive?
For example, in these examples you would want to have the constant value
but don't want to have the binding overhead:
<s:Label text="The {Event.CLICK} event example" />
<EventHandler eventName="{MyEvents.MENU_CLICK}" >
Or is that already happening with constants?
On Tue, Apr 24, 2012 at 12:28 PM, Gordon Smith <go...@adobe.com> wrote:
> Speaking as the person who has written the most complete spec for MXML (at
> far as I know) -- although I'm not currently as an active contributor to
> Apache Flex -- this use of $ in the language strikes me as rather
> arbitrary. Other MXML compiler directives start with @, such as @Embed,
> @Resource, and @{...}. BTW, I see the latter as a poor choice; it should
> have been something like @TwoWay{...} for consistency with the others.
>
> I suggest @Once.
>
> - Gordon
>
> -----Original Message-----
> From: Justin Mclean [mailto:justin@classsoftware.com]
> Sent: Tuesday, April 24, 2012 10:04 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: [jira] [Updated] (FLEX-51) Please check support for
> ExactValue initializer
>
> Hi,
>
> > There is no guarantee of instantiation order in MXML.
> I'm think there's is a defined order for containers and their children to
> be instantiated (ie parent before children) and my (limited) understanding
> was that children are created in order that they are listed in their
> container.
>
> Can you explain the issue is here in a bit more detail? Something to do
> with repeaters or datagroups?
>
> > That's one of the reasons binding is "slow". It evaluates
> > expressions often just in case some portion of the expression suddenly
> becomes available.
> For this patch (as supplied) that wouldn't be an issue as the expression
> would only be evaluated once right?
>
> I think it would be possible to also force an update (if you were having
> an issue) by calling executeBindings? (Not tried)
>
> It's possible to run into timing issues with binding at the moment but
> it's fairly rare. I'm not sure this would increase the risk of that.
>
> Binding had been extended in a similar before with 2 way binding:
> <mx:TextInput id="t1" text="@{t2.text}"/>
>
> So I feel the syntax makes sense at least.
>
> Perhaps some idea of code size/performance gain would give a clearer idea
> if this is a good path to take?
>
> Thanks,
> Justin
>
RE: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Gordon Smith <go...@adobe.com>.
Speaking as the person who has written the most complete spec for MXML (at far as I know) -- although I'm not currently as an active contributor to Apache Flex -- this use of $ in the language strikes me as rather arbitrary. Other MXML compiler directives start with @, such as @Embed, @Resource, and @{...}. BTW, I see the latter as a poor choice; it should have been something like @TwoWay{...} for consistency with the others.
I suggest @Once.
- Gordon
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Tuesday, April 24, 2012 10:04 AM
To: flex-dev@incubator.apache.org
Subject: Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Hi,
> There is no guarantee of instantiation order in MXML.
I'm think there's is a defined order for containers and their children to be instantiated (ie parent before children) and my (limited) understanding was that children are created in order that they are listed in their container.
Can you explain the issue is here in a bit more detail? Something to do with repeaters or datagroups?
> That's one of the reasons binding is "slow". It evaluates
> expressions often just in case some portion of the expression suddenly becomes available.
For this patch (as supplied) that wouldn't be an issue as the expression would only be evaluated once right?
I think it would be possible to also force an update (if you were having an issue) by calling executeBindings? (Not tried)
It's possible to run into timing issues with binding at the moment but it's fairly rare. I'm not sure this would increase the risk of that.
Binding had been extended in a similar before with 2 way binding:
<mx:TextInput id="t1" text="@{t2.text}"/>
So I feel the syntax makes sense at least.
Perhaps some idea of code size/performance gain would give a clearer idea if this is a good path to take?
Thanks,
Justin
RE: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Gordon Smith <go...@adobe.com>.
Then it looks like the parens are necessary for the compiler to recoganize it as an @-directive, which explains why @Once{...} just did string concatenation.
- Gordon
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Monday, April 30, 2012 4:29 PM
To: flex-dev@incubator.apache.org
Subject: Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Hi,
> What does it do with
> <s:TextInput text="@Whatever"/>
It displays "@Whatever".
Also if you have this:
<s:TextInput text="@Embed"/>
It displays "@Embed".
But both of these:
<s:TextInput text="@Embed()"/>
<s:TextInput text="@Embed(something)"/>
Gives an error.
Thanks,
Justin
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> What does it do with
> <s:TextInput text="@Whatever"/>
It displays "@Whatever".
Also if you have this:
<s:TextInput text="@Embed"/>
It displays "@Embed".
But both of these:
<s:TextInput text="@Embed()"/>
<s:TextInput text="@Embed(something)"/>
Gives an error.
Thanks,
Justin
RE: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Gordon Smith <go...@adobe.com>.
What does it do with
<s:TextInput text="@Whatever"/>
?
- Gordon
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Monday, April 30, 2012 3:44 PM
To: flex-dev@incubator.apache.org
Subject: Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Hi
Was just looking into this and creating a few test and I notice that under the current compiler this give a slightly unexpected result:
[Bindable] protected var initial:String = "Hello";
<s:TextInput text="@Once{initial}" />
The initial string value is "@OnceHello". I would of expected it to not compile (or at least a warning) as it doesn't understand @Once.
Binding expression like this are valid, so I assume that what it is going with.
<s:TextInput text="You have {noApples} Apples" />
Anyone think this is a bug? Or that at the very least a warning should be issued?
Thanks,
Justin
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi
Was just looking into this and creating a few test and I notice that under the current compiler this give a slightly unexpected result:
[Bindable] protected var initial:String = "Hello";
<s:TextInput text="@Once{initial}" />
The initial string value is "@OnceHello". I would of expected it to not compile (or at least a warning) as it doesn't understand @Once.
Binding expression like this are valid, so I assume that what it is going with.
<s:TextInput text="You have {noApples} Apples" />
Anyone think this is a bug? Or that at the very least a warning should be issued?
Thanks,
Justin
RE: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Gordon Smith <go...@adobe.com>.
> I think Gordon was referencing the way Falcon is handling binding.
Yes. I'm more familiar with Falcon's approach to databinding than the old compiler's approach, so I was in fact describing what Falcon does. I should have been clearer.
- Gordon
-----Original Message-----
From: Roland Zwaga [mailto:roland@stackandheap.com]
Sent: Wednesday, April 25, 2012 1:48 AM
To: flex-dev@incubator.apache.org
Subject: Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
>
> Below is an example, which illustrates some cases when parsing of the
> binding will fail to determine what change events it should listen to:
>
I think Gordon was referencing the way Falcon is handling binding, Falcon doesn't do MXML->AS3 anymore. It compiles MXML striaght to bytecode.
I don't know if that solves any of this, but your example applies to the way that mxmlc handles things, right?
cheers,
Roland
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Roland Zwaga <ro...@stackandheap.com>.
>
> Adobe didn't publish any specification for MXML and they aren't
> telling what features will be or are planned to for the MXML that will be
> in the new compiler. Suppose we proceed with adding this patch to current
> version of mxmlc - and then Adobe comes up with an incompatible compiler -
> what than?
>
>From what I understood when Falcon gets donated it won't even support full
MXML
compilation, this is something the community will have to create.
Roland
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Left Right <ol...@gmail.com>.
>
> but your example applies to the way
> that mxmlc handles things, right?
>
> Yes, I don't know how Falcon does it.
To be honest, I feel very uncomfortable knowing that MXML will be parsed by
the compiler together with the AS code for the number of reasons I won't
list here because they might be just superficial.
On the other hand, this very fact is something that we also have to
consider if we want to make changes to MXML grammar now. The above change
was suggested to Adobe about 1-2 years ago, but nothing was done on the
matter. Adobe didn't publish any specification for MXML and they aren't
telling what features will be or are planned to for the MXML that will be
in the new compiler. Suppose we proceed with adding this patch to current
version of mxmlc - and then Adobe comes up with an incompatible compiler -
what than?
Best.
Oleg
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Roland Zwaga <ro...@stackandheap.com>.
>
> Below is an example, which illustrates some cases when parsing of the
> binding will fail to determine what change events it should listen to:
>
I think Gordon was referencing the way Falcon is handling binding, Falcon
doesn't do MXML->AS3 anymore. It compiles MXML striaght to bytecode.
I don't know if that solves any of this, but your example applies to the way
that mxmlc handles things, right?
cheers,
Roland
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Left Right <ol...@gmail.com>.
> Are you saying the compiler doesn't determine what the change events for
> each token in the chain? That would definitely be "very far from
reality".
That is some different sort of parsing, it is not based strictly on AS3
grammar, it doesn't contribute to the parse tree generation in the end. In
order to generate parse tree you need to know everything about the lexical
environment you are adding a node to, at that point compiler cannot
possibly know it because the AS3 code that is a part of the environment is
not yet generated. In other words, parse trees are generated on the way
from AS3 to bytecode, not on the way from MXML to AS3.
Below is an example, which illustrates some cases when parsing of the
binding will fail to determine what change events it should listen to:
package actionscript
{
import flash.display.BlendMode;
import flash.events.Event;
import flash.events.EventDispatcher;
import flash.events.IEventDispatcher;
import flash.utils.describeType;
import mx.events.PropertyChangeEvent;
public class BindingChecker extends EventDispatcher
{
[Bindable("propertyChange")]
public function get mode():String
{
// this getter is called only once, when component is set up, but never
again
trace("updating binding");
return this._newMode;
}
private var _oldMode:String;
private var _newMode:String;
private var _modes:Array;
public function BindingChecker(target:IEventDispatcher = null)
{
super(target);
this._newMode = this.getMode();
super.addEventListener(Event.ENTER_FRAME, this.enterFrameHandler);
}
private function enterFrameHandler(event:Event):void
{
this._oldMode = this._newMode;
this._newMode = this.getMode();
super.dispatchEvent(
PropertyChangeEvent.createUpdateEvent(
this, "mode", this._oldMode, this._newMode));
}
private function getMode():String
{
if (!this._modes)
{
this._modes = [];
for each (var mode:XML in describeType(BlendMode).constant.@name)
this._modes.push(BlendMode[mode.toString()]);
}
return this._modes[int(Math.random() * this._modes.length)];
}
}
}
==== using it ====
<mx:UIComponent blendMode="{this.getModes().mode}"/>
<fx:Script>
<![CDATA[
import actionscript.BindingChecker;
private var _checker:BindingChecker;
public function getModes():IEventDispatcher
{
if (!this._checker) this._checker = new BindingChecker(this);
return this._checker;
}
]]>
</fx:Script>
But it is not limited to this situation.
Best.
Oleg
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Om <bi...@gmail.com>.
>
> > In {a.b.c} the compiler has to understand what a, b, and c resolve to,
> what [Bindable] metadata there is on each one, etc. It uses the syntax tree
> and the symbol table to do this.
>
> This is very far from reality. What compiler does is actually like this:
>
> < ... {the expression that appears in between the curly bracket} .../>
> ==>
> var anotherBinding:Function = function():* { return the expression that
> appears in between the curly bracket; }
>
Right. I am pretty sure that changes to a['b'].c will not get executed in
this case, even though it should be resolved the same as a.b.c
Om
On Tue, Apr 24, 2012 at 4:57 PM, Left Right <ol...@gmail.com> wrote:
> > In {a.b.c} the compiler has to understand what a, b, and c resolve to,
> what [Bindable] metadata there is on each one, etc. It uses the syntax tree
> and the symbol table to do this.
>
> This is very far from reality. What compiler does is actually like this:
>
> < ... {the expression that appears in between the curly bracket} .../>
> ==>
> var anotherBinding:Function = function():* { return the expression that
> appears in between the curly bracket; }
>
> It builds the trees and does all the code analysis much-much later after
> all bindings are already generated into AS3 code. So, at the time of
> binding generation the compiler has no idea what's inside the expression.
> It only knows where it copied the expression from so that once the AS3
> lexer or later layers of the compiler find an error, it will know to
> reroute it to the place where the error happened in the original source
> code (which, quite often doesn't work). In some special cases the compiler
> can analyze the type (probably functions, classes, strings), but this is
> rare.
>
> I would also repeat that we are trying to solve the problem too early. We
> really need to have a direction and a plan of what to do with MXML. So far
> it is an ad hoc created set of random rules, it repeats all the mistakes of
> the early programmers (from before 30 years ago at least). This initiative
> is very good in the sense it welcomes this discussion and some more
> analysis, but we really need to formulate the strategy and rules we want to
> keep to when dealing with MXML. There are a lot of things good and bad we
> have to at least compare MXML to before we start making changes.
> Some things to consider:
> cpp (C++ preprocessor and templates)
> Lisp macros
> T4 templates in MSVS
> JSP / Coldfusion
>
> MXML today is a concrete set of rigid arbitrary rules, in terms of the
> development of computer science this roughly equals to the
> early assembler macros predating C and C++, where this was already made
> more generic and configurable.
> I think we could do better than that.
>
> Best.
>
> Oleg
>
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Daniel Wasilewski <de...@gmail.com>.
On 4/25/2012 12:57 AM, Left Right wrote:
>> In {a.b.c} the compiler has to understand what a, b, and c resolve to,
> what [Bindable] metadata there is on each one, etc. It uses the syntax tree
> and the symbol table to do this.
>
> This is very far from reality. What compiler does is actually like this:
>
> < ... {the expression that appears in between the curly bracket} .../>
> ==>
> var anotherBinding:Function = function():* { return the expression that
> appears in between the curly bracket; }
>
> It builds the trees and does all the code analysis much-much later after
> all bindings are already generated into AS3 code. So, at the time of
> binding generation the compiler has no idea what's inside the expression.
> It only knows where it copied the expression from so that once the AS3
> lexer or later layers of the compiler find an error, it will know to
> reroute it to the place where the error happened in the original source
> code (which, quite often doesn't work). In some special cases the compiler
> can analyze the type (probably functions, classes, strings), but this is
> rare.
>
> I would also repeat that we are trying to solve the problem too early. We
> really need to have a direction and a plan of what to do with MXML. So far
> it is an ad hoc created set of random rules, it repeats all the mistakes of
> the early programmers (from before 30 years ago at least). This initiative
> is very good in the sense it welcomes this discussion and some more
> analysis, but we really need to formulate the strategy and rules we want to
> keep to when dealing with MXML. There are a lot of things good and bad we
> have to at least compare MXML to before we start making changes.
> Some things to consider:
> cpp (C++ preprocessor and templates)
> Lisp macros
> T4 templates in MSVS
> JSP / Coldfusion
>
> MXML today is a concrete set of rigid arbitrary rules, in terms of the
> development of computer science this roughly equals to the
> early assembler macros predating C and C++, where this was already made
> more generic and configurable.
> I think we could do better than that.
>
> Best.
>
> Oleg
>
Amen to that!
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Alex Harui <ah...@adobe.com>.
On 4/24/12 4:57 PM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:
>> In {a.b.c} the compiler has to understand what a, b, and c resolve to,
> what [Bindable] metadata there is on each one, etc. It uses the syntax tree
> and the symbol table to do this.
>
> This is very far from reality. What compiler does is actually like this:
>
> < ... {the expression that appears in between the curly bracket} .../>
> ==>
> var anotherBinding:Function = function():* { return the expression that
> appears in between the curly bracket; }
>
> It builds the trees and does all the code analysis much-much later after
> all bindings are already generated into AS3 code. So, at the time of
> binding generation the compiler has no idea what's inside the expression.
> It only knows where it copied the expression from so that once the AS3
> lexer or later layers of the compiler find an error, it will know to
> reroute it to the place where the error happened in the original source
> code (which, quite often doesn't work). In some special cases the compiler
> can analyze the type (probably functions, classes, strings), but this is
> rare.
>
Are you saying the compiler doesn't determine what the change events for
each token in the chain? That would definitely be "very far from reality".
> I would also repeat that we are trying to solve the problem too early. ...
> MXML today is a concrete set of rigid arbitrary rules, in terms of the
> development of computer science this roughly equals to the
> early assembler macros predating C and C++, where this was already made
> more generic and configurable.
> I think we could do better than that.
Then do it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Left Right <ol...@gmail.com>.
> In {a.b.c} the compiler has to understand what a, b, and c resolve to,
what [Bindable] metadata there is on each one, etc. It uses the syntax tree
and the symbol table to do this.
This is very far from reality. What compiler does is actually like this:
< ... {the expression that appears in between the curly bracket} .../>
==>
var anotherBinding:Function = function():* { return the expression that
appears in between the curly bracket; }
It builds the trees and does all the code analysis much-much later after
all bindings are already generated into AS3 code. So, at the time of
binding generation the compiler has no idea what's inside the expression.
It only knows where it copied the expression from so that once the AS3
lexer or later layers of the compiler find an error, it will know to
reroute it to the place where the error happened in the original source
code (which, quite often doesn't work). In some special cases the compiler
can analyze the type (probably functions, classes, strings), but this is
rare.
I would also repeat that we are trying to solve the problem too early. We
really need to have a direction and a plan of what to do with MXML. So far
it is an ad hoc created set of random rules, it repeats all the mistakes of
the early programmers (from before 30 years ago at least). This initiative
is very good in the sense it welcomes this discussion and some more
analysis, but we really need to formulate the strategy and rules we want to
keep to when dealing with MXML. There are a lot of things good and bad we
have to at least compare MXML to before we start making changes.
Some things to consider:
cpp (C++ preprocessor and templates)
Lisp macros
T4 templates in MSVS
JSP / Coldfusion
MXML today is a concrete set of rigid arbitrary rules, in terms of the
development of computer science this roughly equals to the
early assembler macros predating C and C++, where this was already made
more generic and configurable.
I think we could do better than that.
Best.
Oleg
RE: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Gordon Smith <go...@adobe.com>.
> I'm pretty sure the binding code in the compiler knows about every token in the expression as it knows what the change events are for each token.
In {a.b.c} the compiler has to understand what a, b, and c resolve to, what [Bindable] metadata there is on each one, etc. It uses the syntax tree and the symbol table to do this.
- Gordon
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Tuesday, April 24, 2012 3:32 PM
To: flex-dev@incubator.apache.org
Subject: Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
On 4/24/12 12:07 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> There is certainly an order today for children in a container, but I
>> don't think it has been documented
> HBox and VBox and horizontal and vertical layouts probably wouldn't
> work as expected if this changed.
I disagree. We could change the order of creation from as long as we add them in the right order.
>
>
>> We'll get puzzled users where the value is assigned as null
> For the most common use case ie const + "const" expressions there's no issue.
Yeah, so can we just limit this optimization to constant expressions?
>
>> Optimizing for constant expressions is a good thing, but I still
>> think it can be done without a syntax change.
> You have anything you can submit or code we can look at?
I don't know the binding code that well and would recommend waiting for Falcon to learn it, but I'm pretty sure the binding code in the compiler knows about every token in the expression as it knows what the change events are for each token. It knows about literals since they don't have change events. It knows about the __NoChangeEvent__ event and I believe it generates different code for it. And I think it already knows about constants today as well.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Alex Harui <ah...@adobe.com>.
On 4/24/12 12:07 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> There is certainly an order today for children in a container, but I don't
>> think it has been documented
> HBox and VBox and horizontal and vertical layouts probably wouldn't work as
> expected if this changed.
I disagree. We could change the order of creation from as long as we add
them in the right order.
>
>
>> We'll get puzzled users where the value is assigned as null
> For the most common use case ie const + "const" expressions there's no issue.
Yeah, so can we just limit this optimization to constant expressions?
>
>> Optimizing for constant expressions is a good thing, but I still think it
>> can be done without a syntax change.
> You have anything you can submit or code we can look at?
I don't know the binding code that well and would recommend waiting for
Falcon to learn it, but I'm pretty sure the binding code in the compiler
knows about every token in the expression as it knows what the change events
are for each token. It knows about literals since they don't have change
events. It knows about the __NoChangeEvent__ event and I believe it
generates different code for it. And I think it already knows about
constants today as well.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> There is certainly an order today for children in a container, but I don't
> think it has been documented
HBox and VBox and horizontal and vertical layouts probably wouldn't work as expected if this changed.
> It is further complicated by depth and states.
I can see that could complicate things. May be possible for the bindings to execute once before needed components have been created if you are using states.
> We'll get puzzled users where the value is assigned as null
For the most common use case ie const + "const" expressions there's no issue. Most users (unless they wanted to optimise performance) are likely to continue to use existing normal binding.
There is also a very simple fix if something doesn't work the way you expected - just go back to using normal binding.
> Optimizing for constant expressions is a good thing, but I still think it
> can be done without a syntax change.
You have anything you can submit or code we can look at? It certainly sounds like a sound approach but I no idea how much work it would take.
Thanks,
Justin
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Alex Harui <ah...@adobe.com>.
On 4/24/12 10:04 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> There is no guarantee of instantiation order in MXML.
> I'm think there's is a defined order for containers and their children to be
> instantiated (ie parent before children) and my (limited) understanding was
> that children are created in order that they are listed in their container.
>
> Can you explain the issue is here in a bit more detail? Something to do with
> repeaters or datagroups?
There is certainly an order today for children in a container, but I don't
think it has been documented and I wouldn't want to guarantee it if it
hasn't. It is further complicated by depth and states.
I'm pretty sure the order of instantiation of things in fx:Declarations vs
display object children is different from the order of non-display object
children vs display object children in Flex 3. Again, I would not want to
guarantee it. There might be startup time optimizations to be gained by
changing the order/timing.
>
>> That's one of the reasons binding is "slow". It evaluates expressions often
>> just in case some
>> portion of the expression suddenly becomes available.
> For this patch (as supplied) that wouldn't be an issue as the expression would
> only be evaluated once right?
My point is that there is no way to guarantee the value of the expression at
the time of evaluation. We'll get puzzled users where the value is assigned
as null, but when looking in the debugger a short while later it won't be
null.
>
> I think it would be possible to also force an update (if you were having an
> issue) by calling executeBindings? (Not tried)
Maybe, but if the evaluation causes a change in the value of some other
expression you will still have problems.
>
> It's possible to run into timing issues with binding at the moment but it's
> fairly rare. I'm not sure this would increase the risk of that.
Supposedly, the binding subsystem evaluates often enough that there is no
risk of timing. This isn't true for developer-created bindings using
fx:Binding. Again, for constant expressions, there is little chance for
timing issues, but for a complex network of bindings to variable expressions
I think you are asking for trouble.
>
> Binding had been extended in a similar before with 2 way binding:
> <mx:TextInput id="t1" text="@{t2.text}"/>
>
> So I feel the syntax makes sense at least.
Yes, I don't have a problem with the proposed syntax.
>
> Perhaps some idea of code size/performance gain would give a clearer idea if
> this is a good path to take?
Optimizing for constant expressions is a good thing, but I still think it
can be done without a syntax change. I believe the compiler knows enough
about the parts of an expression to rule that all parts are constants or
literals.
Optimizing for read-once variable expressions just sounds dangerous to me.
I would not want to bake that into the compiler and invite people into a
trap.
One way to find out how such a thing would work in the real world without
changing the compiler is to create a custom helper class that does
essentially the same thing. Folks can then try out using a SetOnceBinding
class and we'll see how often folks get burned by it. I was looking into
other specific binding helper classes to optimize bindings for itemrenderers
and skins when 11/11 hit.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> There is no guarantee of instantiation order in MXML.
I'm think there's is a defined order for containers and their children to be instantiated (ie parent before children) and my (limited) understanding was that children are created in order that they are listed in their container.
Can you explain the issue is here in a bit more detail? Something to do with repeaters or datagroups?
> That's one of the reasons binding is "slow". It evaluates expressions often just in case some
> portion of the expression suddenly becomes available.
For this patch (as supplied) that wouldn't be an issue as the expression would only be evaluated once right?
I think it would be possible to also force an update (if you were having an issue) by calling executeBindings? (Not tried)
It's possible to run into timing issues with binding at the moment but it's fairly rare. I'm not sure this would increase the risk of that.
Binding had been extended in a similar before with 2 way binding:
<mx:TextInput id="t1" text="@{t2.text}"/>
So I feel the syntax makes sense at least.
Perhaps some idea of code size/performance gain would give a clearer idea if this is a good path to take?
Thanks,
Justin
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Alex Harui <ah...@adobe.com>.
On 4/24/12 8:52 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> Should it be binding until the first (not null) assignment
>> is made and then detach itself? Just run on creation complete and then
>> never again?
>
> If you look at the patch no binding is set up but the value is just set in
> when the component is created internally via new (ie way before creation
> complete).
There is no guarantee of instantiation order in MXML. That's one of the
reasons binding is "slow". It evaluates expressions often just in case some
portion of the expression suddenly becomes available. I can see optimizing
for a constant expression, but if there are variables, I think some folks
are going to get burned by timing problems.
>
> Although waiting until first non null value also sounds like an interesting
> idea.
Waiting requires essentially the same code as binding.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Should it be binding until the first (not null) assignment
> is made and then detach itself? Just run on creation complete and then
> never again?
If you look at the patch no binding is set up but the value is just set in when the component is created internally via new (ie way before creation complete).
Although waiting until first non null value also sounds like an interesting idea.
Thanks,
Justin
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Сергей aSt Егоров <bs...@gmail.com>.
No, value can be any AS3 value syntax like:
prop="${MyConstPool.getAnyConst("const" + (5 * 10) + myVar) + "suffix"}"
That's why we can't just add CONST recognizer to the bindings
On Tue, Apr 24, 2012 at 7:23 PM, Jonathan Campos <jo...@gmail.com> wrote:
> On Tue, Apr 24, 2012 at 10:18 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> If not, how will you know when to assign the value?
>
>
> Dang Alex, you beat me to it. That was my issue with this idea. When is the
> value assigned? Should it be binding until the first (not null) assignment
> is made and then detach itself? Just run on creation complete and then
> never again?
>
> Seems problematic.
>
> --
> Jonathan Campos
--
С уважением, Сергей Егоров
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Jonathan Campos <jo...@gmail.com>.
On Tue, Apr 24, 2012 at 10:18 AM, Alex Harui <ah...@adobe.com> wrote:
> If not, how will you know when to assign the value?
Dang Alex, you beat me to it. That was my issue with this idea. When is the
value assigned? Should it be binding until the first (not null) assignment
is made and then detach itself? Just run on creation complete and then
never again?
Seems problematic.
--
Jonathan Campos
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Сергей aSt Егоров <bs...@gmail.com>.
Hi everybody!
Thanks for your replies!
When i wrote this change, i was worried about backward compatibility,
so i did everything to make it work properly without conflicts with
bindings and other things, also, implementation is similar to bindings
and it's parsed well, i suggest
On Tue, Apr 24, 2012 at 6:06 PM, Roland Zwaga <ro...@stackandheap.com> wrote:
> Hi there,
>
> I welcome this addition as well! I've had plenty of times when I just
> wanted to assign a value once, without binding, when I still needed the
> curly braces because otherwise the compiler would just see the value as a
> literal.
> From what I can gather, this wouldn't have any bad effects on anything else.
>
> cheerios,
>
> Roland
>
> On 24 April 2012 15:50, Justin Mclean <ju...@classsoftware.com> wrote:
>
>> Hi,
>>
>> I think this is a nice idea. As this involves an addition to MXML syntax
>> (ie attr="${value}" rather than attr="{value}" to bind to value once) does
>> anyone have any suggestions on how we can take this forward?
>>
>> Are there any disadvantages/issues that if this was applied that I'm not
>> seeing?
>>
>> Thanks,
>> Justin
>
>
>
>
> --
> regards,
> Roland
>
> --
> Roland Zwaga
> Senior Consultant | Stack & Heap BVBA
>
> +32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com
--
С уважением, Сергей Егоров
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Сергей aSt Егоров <bs...@gmail.com>.
I didn't see anything bad when you use ${} to work with a non const
values, because it's created exactly for this flow (when we needs
evaluate some expression once, without binding)
On Tue, Apr 24, 2012 at 7:43 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> If so, why do we want to add syntax instead of having the compiler figure out that the value will
>> never change?
> That would be ideal but probably much more complex to implement than this patch. It may also we hard to work out if an expression as opposed to a variable is "constant" or not.
>
> I'm not sure the MXML compiler (at this stage of compilation) can even work if the value will actually change or not? Anyone know?
>
>> If not, how will you know when to assign the value?
> I think it would safe to assume that it's the initial assigned value. The intended use case (correct me here if I wrong) would be generally along the lines of:
>
> public static const WIDTH:int = 200;
>
> <s:List width="${WIDTH}" height="${WIDTH/2}" />
>
> Might be a good idea to issue a compiler warning if you $ bind to a non const variable or expression but not stop you from doing that.
>
> Thanks,
> Justin
>
--
С уважением, Сергей Егоров
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> If so, why do we want to add syntax instead of having the compiler figure out that the value will
> never change?
That would be ideal but probably much more complex to implement than this patch. It may also we hard to work out if an expression as opposed to a variable is "constant" or not.
I'm not sure the MXML compiler (at this stage of compilation) can even work if the value will actually change or not? Anyone know?
> If not, how will you know when to assign the value?
I think it would safe to assume that it's the initial assigned value. The intended use case (correct me here if I wrong) would be generally along the lines of:
public static const WIDTH:int = 200;
<s:List width="${WIDTH}" height="${WIDTH/2}" />
Might be a good idea to issue a compiler warning if you $ bind to a non const variable or expression but not stop you from doing that.
Thanks,
Justin
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by Alex Harui <ah...@adobe.com>.
Is this only for binding to consts and literals? If so, why do we want to
add syntax instead of having the compiler figure out that the value will
never change? If not, how will you know when to assign the value?
On 4/24/12 7:06 AM, "Roland Zwaga" <ro...@stackandheap.com> wrote:
> Hi there,
>
> I welcome this addition as well! I've had plenty of times when I just
> wanted to assign a value once, without binding, when I still needed the
> curly braces because otherwise the compiler would just see the value as a
> literal.
> From what I can gather, this wouldn't have any bad effects on anything else.
>
> cheerios,
>
> Roland
>
> On 24 April 2012 15:50, Justin Mclean <ju...@classsoftware.com> wrote:
>
>> Hi,
>>
>> I think this is a nice idea. As this involves an addition to MXML syntax
>> (ie attr="${value}" rather than attr="{value}" to bind to value once) does
>> anyone have any suggestions on how we can take this forward?
>>
>> Are there any disadvantages/issues that if this was applied that I'm not
>> seeing?
>>
>> Thanks,
>> Justin
>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Roland Zwaga <ro...@stackandheap.com>.
Hi there,
I welcome this addition as well! I've had plenty of times when I just
wanted to assign a value once, without binding, when I still needed the
curly braces because otherwise the compiler would just see the value as a
literal.
>From what I can gather, this wouldn't have any bad effects on anything else.
cheerios,
Roland
On 24 April 2012 15:50, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> I think this is a nice idea. As this involves an addition to MXML syntax
> (ie attr="${value}" rather than attr="{value}" to bind to value once) does
> anyone have any suggestions on how we can take this forward?
>
> Are there any disadvantages/issues that if this was applied that I'm not
> seeing?
>
> Thanks,
> Justin
--
regards,
Roland
--
Roland Zwaga
Senior Consultant | Stack & Heap BVBA
+32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com
Re: [jira] [Updated] (FLEX-51) Please check support for ExactValue initializer
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I think this is a nice idea. As this involves an addition to MXML syntax (ie attr="${value}" rather than attr="{value}" to bind to value once) does anyone have any suggestions on how we can take this forward?
Are there any disadvantages/issues that if this was applied that I'm not seeing?
Thanks,
Justin
[jira] [Updated] (FLEX-51) Please check support for ExactValue
initializer
Posted by "Sergey Egorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FLEX-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Egorov updated FLEX-51:
------------------------------
Description:
I've done my own improvement for MXML to support any values for property initializer WITHOUT bindings, for example:
Was:
<TextField xmlns="flash.text.*" autoSize="{TextFieldAutoSize.CENTER}" />
is generated into:
private function _MyOwnFlexFrameworkTest_TextField1_i() : flash.text.TextField
{
var temp : flash.text.TextField = new flash.text.TextField();
_MyOwnFlexFrameworkTest_TextField1 = temp;
mx.binding.BindingManager.executeBindings(this, "_MyOwnFlexFrameworkTest_TextField1", _MyOwnFlexFrameworkTest_TextField1);
return temp;
}
// binding mgmt
private function _MyOwnFlexFrameworkTest_bindingsSetup():Array
{
var result:Array = [];
result[0] = new mx.binding.Binding(this,
function():String
{
var result:* = (TextFieldAutoSize.CENTER);
return (result == undefined ? null : String(result));
},
null,
"_MyOwnFlexFrameworkTest_TextField1.autoSize"
);
return result;
}
now:
<TextField xmlns="flash.text.*" autoSize="${TextFieldAutoSize.CENTER}" />
give us such result:
private function _MyOwnFlexFrameworkTest_TextField1_i() : flash.text.TextField
{
var temp : flash.text.TextField = new flash.text.TextField();
temp.autoSize = TextFieldAutoSize.CENTER;
_MyOwnFlexFrameworkTest_TextField1 = temp;
mx.binding.BindingManager.executeBindings(this, "_MyOwnFlexFrameworkTest_TextField1", _MyOwnFlexFrameworkTest_TextField1);
return temp;
}
this implementation is similar to twoWay bindings and written in the same way.
btw, sorry for my English, I'm Russian.
Thanks
was:
I've done my own improvement for MXML to support any values for property initializer WITHOUT bindings, for example:
Was:
<TextField xmlns="flash.text.*" autoSize="{TextFieldAutoSize.CENTER}" />
is generated into:
private function _MyOwnFlexFrameworkTest_TextField1_i() : flash.text.TextField
{
var temp : flash.text.TextField = new flash.text.TextField();
_MyOwnFlexFrameworkTest_TextField1 = temp;
mx.binding.BindingManager.executeBindings(this, "_MyOwnFlexFrameworkTest_TextField1", _MyOwnFlexFrameworkTest_TextField1);
return temp;
}
// binding mgmt
private function _MyOwnFlexFrameworkTest_bindingsSetup():Array
{
var result:Array = [];
result[0] = new mx.binding.Binding(this,
function():String
{
var result:* = (TextFieldAutoSize.CENTER);
return (result == undefined ? null : String(result));
},
null,
"_MyOwnFlexFrameworkTest_TextField1.autoSize"
);
return result;
}
now:
<TextField xmlns="flash.text.*" autoSize="${TextFieldAutoSize.CENTER}" />
give us such result:
private function _MyOwnFlexFrameworkTest_TextField1_i() : flash.text.TextField
{
var temp : flash.text.TextField = new flash.text.TextField();
temp.autoSize = TextFieldAutoSize.CENTER;
_MyOwnFlexFrameworkTest_TextField1 = temp;
mx.binding.BindingManager.executeBindings(this, "_MyOwnFlexFrameworkTest_TextField1", _MyOwnFlexFrameworkTest_TextField1);
return temp;
}
this implementation is similar to twoWay bindings and written in the same way.
here is the patch:
http://dl.dropbox.com/u/18819203/exactValue.patch
btw, sorry for my English, I'm Russian.
Thanks
> Please check support for ExactValue initializer
> -----------------------------------------------
>
> Key: FLEX-51
> URL: https://issues.apache.org/jira/browse/FLEX-51
> Project: Apache Flex
> Issue Type: Improvement
> Reporter: Sergey Egorov
> Assignee: Bertrand Delacretaz
> Priority: Minor
> Attachments: exactValue.patch
>
>
> I've done my own improvement for MXML to support any values for property initializer WITHOUT bindings, for example:
> Was:
> <TextField xmlns="flash.text.*" autoSize="{TextFieldAutoSize.CENTER}" />
> is generated into:
> private function _MyOwnFlexFrameworkTest_TextField1_i() : flash.text.TextField
> {
> var temp : flash.text.TextField = new flash.text.TextField();
> _MyOwnFlexFrameworkTest_TextField1 = temp;
> mx.binding.BindingManager.executeBindings(this, "_MyOwnFlexFrameworkTest_TextField1", _MyOwnFlexFrameworkTest_TextField1);
> return temp;
> }
> // binding mgmt
> private function _MyOwnFlexFrameworkTest_bindingsSetup():Array
> {
> var result:Array = [];
> result[0] = new mx.binding.Binding(this,
> function():String
> {
> var result:* = (TextFieldAutoSize.CENTER);
> return (result == undefined ? null : String(result));
> },
> null,
> "_MyOwnFlexFrameworkTest_TextField1.autoSize"
> );
> return result;
> }
> now:
> <TextField xmlns="flash.text.*" autoSize="${TextFieldAutoSize.CENTER}" />
> give us such result:
> private function _MyOwnFlexFrameworkTest_TextField1_i() : flash.text.TextField
> {
> var temp : flash.text.TextField = new flash.text.TextField();
> temp.autoSize = TextFieldAutoSize.CENTER;
> _MyOwnFlexFrameworkTest_TextField1 = temp;
> mx.binding.BindingManager.executeBindings(this, "_MyOwnFlexFrameworkTest_TextField1", _MyOwnFlexFrameworkTest_TextField1);
> return temp;
> }
> this implementation is similar to twoWay bindings and written in the same way.
> btw, sorry for my English, I'm Russian.
> Thanks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira