Re: [FlexJX][Falcon] Binding support fixes/improvements

[sankar]

sankar wrote
> 
> PKumar wrote
>> @Sankar, FlexJS  binding support is not similar to regular Flex SDK
>> binding and FlexJS DataGrid. FlexJS having the supported classes for
>> runtime data update in DataGrid and dataprovider. If you need  the sample
>> code. i will check in my demo list & share with you.
> I'd love to see how this working, thanks PKumar!

@PKumar, is any input available for me? Please, suggest.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJX-Falcon-Binding-support-fixes-improvements-tp54632p57168.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJX][Falcon] Binding support fixes/improvements

[sankar]

PKumar wrote
> @Sankar, FlexJS  binding support is not similar to regular Flex SDK
> binding and FlexJS DataGrid. FlexJS having the supported classes for
> runtime data update in DataGrid and dataprovider. If you need  the sample
> code. i will check in my demo list & share with you.

I'd love to see how this working, thanks PKumar!


Peter Ent wrote
> I have assigned the JIRA issue to myself and will be looking into this.

That's great!



--
View this message in context: 
http://apache-flex-development.2333347.n4.nabble.com/FlexJX-Falcon-Binding-support-fixes-improvements-tp54632p57044.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Peter Ent]

I have assigned the JIRA issue to myself and will be looking into this.
‹peter

On 12/6/16, 1:11 AM, "sankar" <santanu4...@gmail.com> wrote:

>Can Peter or anyone from Apache dev suggest where the present development
>stays for runtime data update to DataGrid component, or even any specific
>beads way already available, as discussed in earlier comments/queries?
>
>I think it's very much essential to me as a Flex developer to have the
>runtime update feature available to DataGrid component. I understood
>FlexJS
>works per pay-as-you-go ideology. But yet it's a critical feature that
>many
>of us developers would want in their project, and I am sure about it.
>
>I have raised a JIRA question on this:
>https://issues.apache.org/jira/browse/FLEX-35197.
>
>It'd be great to hear from the devs on this.
>
>Thanks!
>
>
>
>--
>View this message in context:
>http://apache-flex-development.247.n4.nabble.com/FlexJX-Falcon-Binding
>-support-fixes-improvements-tp54632p57023.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJX][Falcon] Binding support fixes/improvements

[PKumar]

@Sankar, FlexJS  binding support is not similar to regular Flex SDK binding
and FlexJS DataGrid. FlexJS having the supported classes for runtime data
update in DataGrid and dataprovider. If you need  the sample code. i will
check in my demo list & share with you.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJX-Falcon-Binding-support-fixes-improvements-tp54632p57041.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJX][Falcon] Binding support fixes/improvements

[sankar]

Can Peter or anyone from Apache dev suggest where the present development
stays for runtime data update to DataGrid component, or even any specific
beads way already available, as discussed in earlier comments/queries?

I think it's very much essential to me as a Flex developer to have the
runtime update feature available to DataGrid component. I understood FlexJS
works per pay-as-you-go ideology. But yet it's a critical feature that many
of us developers would want in their project, and I am sure about it.

I have raised a JIRA question on this:
https://issues.apache.org/jira/browse/FLEX-35197. 

It'd be great to hear from the devs on this.

Thanks!



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJX-Falcon-Binding-support-fixes-improvements-tp54632p57023.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 12/1/16, 8:21 PM, "sankar"  wrote:

>
>> Alex Harui wrote
>> Peter knows this example better, so I'll ask him to answer.
>
>That sounds good! 
>
>
>> Alex Harui wrote
>> I envision several kinds of view,
>> controller and model beads to manage this complexity.  I'm not sure
>>which 
>> ones have been built yet.
>
>
>
>I also wondering such level of process may requires addition of different
>DataGrid specific beads (i.e. data-binding etc.), but are they available
>any, to listen the collection change event from it's dataProvider.
>
>

I don't know which ones have been built yet.  Peter may know better.  I
expect that someday there will be a feature rich DG with the the most
complex beads that folks will use because it will have everything they
want in it, and will re-compose with lighter weight beads if they need it.

-Alex

Re: [FlexJX][Falcon] Binding support fixes/improvements

[sankar]

--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJX-Falcon-Binding-support-fixes-improvements-tp54632p56908.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

Peter knows this example better, so I'll ask him to answer.  Keep in mind
that with pay-as-you-go, every level of functionality adds code.  The
smallest DG would not expect any changes:  it would just display the data
in its columns.  The next level of change support is adding and removing
whole rows.  After that comes replacing a row, then we get into changing
fields in the rows.  Each level adds more code and complexity in handling
things like selectedItem/selectedIndex.  I envision several kinds of view,
controller and model beads to manage this complexity.  I'm not sure which
ones have been built yet.

-Alex

On 12/1/16, 2:35 AM, "sankar" <santanu4...@gmail.com> wrote:

>Alex Harui wrote
>> But I think there isn't any code that will send itemUpdated if a field
>>in
>> an item
>> changes, only if an item changes.
>
>Does the above means that if I updates a whole item, it suppose to reflect
>to the row UI? Does DataGrid has necessary codes to listen itemUpdate
>event
>at all, or what we need to do if it can't?
>
>I tried to add a new item to the ArrayList; I also noticed the ArrayList
>has
>/'propertyChange'/ event, but don't know if that suppose to work with
>DataGrid:
>
>> var tmp:Product = new
>> Product("ps220","Weejets",35,190,"assets/smallorangerect.jpg")
>> ProductsModel(applicationModel).productList.addItem(tmp);
>> 
>> ...
>> // inside model 
>> [Bindable(event="propertyChange")]
>> public function get productList():ArrayList
>> {
>>  return _productList;
>> }
>>  
>> public function set productList(value:ArrayList):void
>> {
>>  if (value != _productList)
>>  {
>>      _productList = value;
>>  dispatchEvent(new Event("propertyChange"));
>>  }
>> }
>
>
>
>
>
>--
>View this message in context:
>http://apache-flex-development.247.n4.nabble.com/FlexJX-Falcon-Binding
>-support-fixes-improvements-tp54632p56868.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJX][Falcon] Binding support fixes/improvements

[sankar]

Alex Harui wrote
> But I think there isn't any code that will send itemUpdated if a field in
> an item
> changes, only if an item changes.

Does the above means that if I updates a whole item, it suppose to reflect
to the row UI? Does DataGrid has necessary codes to listen itemUpdate event
at all, or what we need to do if it can't?

I tried to add a new item to the ArrayList; I also noticed the ArrayList has
/'propertyChange'/ event, but don't know if that suppose to work with
DataGrid:

> var tmp:Product = new
> Product("ps220","Weejets",35,190,"assets/smallorangerect.jpg")
> ProductsModel(applicationModel).productList.addItem(tmp);
> 
> ...
> // inside model 
> [Bindable(event="propertyChange")]
> public function get productList():ArrayList
> {
>   return _productList;
> }
>   
> public function set productList(value:ArrayList):void
> {
>   if (value != _productList)
>   {
>   _productList = value;
>   dispatchEvent(new Event("propertyChange"));
>   }
> }





--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJX-Falcon-Binding-support-fixes-improvements-tp54632p56868.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 11/30/16, 9:25 PM, "sankar"  wrote:

>Alex Harui wrote
>> You should be able to convert ProductItemRenderer to MXML and use
>> data-binding, or just have the AS version listen for the appropriate
>>event
>> fired from the data item.
>
>I've tried to create a new MXML component based on DataItemRenderer, but I
>couldn't even build compiler starts showing this error:
>
>/1551: Internal error in ABC generator subsystem, when generating code
>for:
>E:\apache-flex-flexjs-0.8.0-bin\examples\flexjs\DataGridExample\src\produc
>ts\ProductItemRendererMXML.mxml:
>java.lang.NullPointerException
>/
>Is that class supposed to be extended as MXML component?

If you get an internal error, that's probably a bug in the compiler.  File
a JIRA issue with the renderer.  There is probably some pattern you are
using that is fooling the compiler.

>
>
>Alex Harui wrote
>> Because of the pay-as-you-go philosophy, the data
>> provider used in the example does not dispatch collection change events,
>> and the DataGrid and renderers aren't listening for it.
>
>What alteration do I need to make the example works to dispatch collection
>change event and DataGrid/renderers listens to it?
>

It looks like DataGridExample is already using ArrayList.  But I think
there isn't any code that will send itemUpdated if a field in an item
changes, only if an item changes.  If you can get itemUpdated to dispatch
you can then see if any code is listening and will do the right thing, but
it might be less work to have a custom renderer with binding like you
tried above.

HTH,
-Alex

Re: [FlexJX][Falcon] Binding support fixes/improvements

[sankar]

Alex Harui wrote
> You should be able to convert ProductItemRenderer to MXML and use
> data-binding, or just have the AS version listen for the appropriate event
> fired from the data item.

I've tried to create a new MXML component based on DataItemRenderer, but I
couldn't even build compiler starts showing this error:

/1551: Internal error in ABC generator subsystem, when generating code for:
E:\apache-flex-flexjs-0.8.0-bin\examples\flexjs\DataGridExample\src\products\ProductItemRendererMXML.mxml:
java.lang.NullPointerException
/
Is that class supposed to be extended as MXML component?


Alex Harui wrote
> Because of the pay-as-you-go philosophy, the data
> provider used in the example does not dispatch collection change events,
> and the DataGrid and renderers aren't listening for it.

What alteration do I need to make the example works to dispatch collection
change event and DataGrid/renderers listens to it?



--
View this message in context: 
http://apache-flex-development.2333347.n4.nabble.com/FlexJX-Falcon-Binding-support-fixes-improvements-tp54632p56850.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 11/30/16, 12:44 AM, "sankar"  wrote:

>I was recently testing 0.8.0 FlexJS nightly build, and I must say binding
>is
>more responsive here than 0.7.0 version. I was testing by the example
>project 'DataGridExample', and my interest was to see if data binding is
>working in grid item renderer as well. Is this doable with present nightly
>build?
>
>At runtime upon a button click I tried to modify an item row in
>/MyInitialView.mxml/ as this:
>
>> private function onButtonClicked():void
>> {
>>  ProductsModel(applicationModel).productList.source[1].image =
>> "assets/smallorangerect.jpg";
>> }
>
>I tit-bit tried to dispatch event upon change here and there too, but that
>didn't effect DataGrid UI change, get/set method in DataItemRenderer also
>not being called. 
>
>Is there any way in current nightly build that we can meet the above
>requirement?

I assume you are still using the ProductItemRenderer in the example?  It
is written in ActionScript, so there is no compiler-generated data-binding
in the renderer.  Because of the pay-as-you-go philosophy, the data
provider used in the example does not dispatch collection change events,
and the DataGrid and renderers aren't listening for it.

You should be able to convert ProductItemRenderer to MXML and use
data-binding, or just have the AS version listen for the appropriate event
fired from the data item.

HTH,
-Alex

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

>For the patch mentioned below, will you apply that to develop? Or do you
>want me to do that sometime tomorrow?

Now that you are a committer, you can do it yourself!

I will! Will do that later today. :)



What do you mean by "pure".  That it is a direct result of the parsing?
We don't have to finish this discussion now, I just want to stick in the
back of my head for a while.

I guess it is easier to describe it in terms of my personal analogy (which
as I said, may not apply in compiler-land in general, or specifically here)

If the Typed defintion representation of the AST is like the vector data in
a displayobject, then, I am thinking of [Bindable]'s implicit
implementation as possibly more like a Matrix or ColorTransform


Perhaps there is a way to do something like this already in the compiler
code and I just have not discovered it yet. iirc I think I did see some
'isImplicit()' methods.
Vaguely, I am thinking sort of like:
IDefintion {

extras:
Boolean isTransformed() //might be useful to know that this is 'virtual'


Boolean getHasTransforms()

IDefintion getTransformedDefintion()

set/clear transforms support methods etc... IDefinitionTransformer
}



IDefinitionTransformer { //e.g. [Bindable] on class or [Bindable] on var

Boolean isApplicableFor(IDefinition dev); //then add it to the collection
above (e.g. check if the class definition has 'Bindable')

void applyTo(IDefintion proxyDefinition); //called in sequence inside
getTransformedDefintion()
above
}

example:
definitionForOutput = class_defintion.getHasTransforms() ?
class_defintion. getTransformedDefintion()
: class_defintion;

getHasTransforms would create a proxy clone of the original definition and
then apply the transforms and cache the result for subsequent requests.


If the doc emitters are also driven from the type definitions (I think they
are?), then the above approach might permit docgen from the transformed
definitions as well.

But probably none of this really makes sense unless:

a) we can conceive of a scenario where one pass of the AST can result in
multiple outputs with different variations of transformed output
(transforms would be changed between outputs)
and/or
b) we want to make metadata-driven (or possibly other types of) output
transformations extensible

As I think you pointed out, Bindable (convenience) implementations would
only be an easy candidate for  'swappable' (e.g. for as3 signal based
implementation etc) if there were no explicit implementations of
getters/setters elsewhere in the project.

None of this is something I specifically 'want', it's just my mind
wandering. I should stop my ponderings here :) None of this may be relevant
- if you think it is useful to revisit, as you said, we can do so later.





On Thu, Sep 8, 2016 at 4:37 AM, Alex Harui  wrote:

>
>
> On 9/7/16, 1:11 AM, "Greg Dove"  wrote:
>
> >I can see advantages either way, but had assumed that longer term it may
> >be
> >advantageous to keep the AST/Typed AST more 'pure'
>
> What do you mean by "pure".  That it is a direct result of the parsing?
> We don't have to finish this discussion now, I just want to stick in the
> back of my head for a while.
>
> >
> >Re : "It is a convenience feature: the compiler could just report an error
> >saying you can't use [Bindable] on Objects."
> >I guess that is always another option. :)
> >[Bindable] implicit implementation was many times overused by some Flex
> >developers in the past, I was probably guilty of this myself in the early
> >days. But it is quite handy and quick sometimes, so long as you know the
> >implications of its use/abuse. And if it is taken away now I am pretty
> >sure
> >sdk users will ask for it back ;)
>
> I wouldn't take away the [Bindable] on Objects feature, I was just
> pointing out that it really is a shortcut to writing the proper source
> code.  If I could, I would actually have the compiler alter the source
> file.  Otherwise, imagine how surprised you are when you see a call to
> super() or debug into super() and it doesn't go to Object.
>
> IMO, implementing [Bindable] by hacking the AST is sort of like having a
> preprocessor phase (which the former Falcon engineers were very much
> against).  I still ponder the notion of metadata-as-macros and having
> [Bindable] be one of them.
>
> >
> >For the patch mentioned below, will you apply that to develop? Or do you
> >want me to do that sometime tomorrow?
>
> Now that you are a committer, you can do it yourself!
>
> -Alex
>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 9/7/16, 1:11 AM, "Greg Dove"  wrote:

>I can see advantages either way, but had assumed that longer term it may
>be
>advantageous to keep the AST/Typed AST more 'pure'

What do you mean by "pure".  That it is a direct result of the parsing?
We don't have to finish this discussion now, I just want to stick in the
back of my head for a while.

>
>Re : "It is a convenience feature: the compiler could just report an error
>saying you can't use [Bindable] on Objects."
>I guess that is always another option. :)
>[Bindable] implicit implementation was many times overused by some Flex
>developers in the past, I was probably guilty of this myself in the early
>days. But it is quite handy and quick sometimes, so long as you know the
>implications of its use/abuse. And if it is taken away now I am pretty
>sure
>sdk users will ask for it back ;)

I wouldn't take away the [Bindable] on Objects feature, I was just
pointing out that it really is a shortcut to writing the proper source
code.  If I could, I would actually have the compiler alter the source
file.  Otherwise, imagine how surprised you are when you see a call to
super() or debug into super() and it doesn't go to Object.

IMO, implementing [Bindable] by hacking the AST is sort of like having a
preprocessor phase (which the former Falcon engineers were very much
against).  I still ponder the notion of metadata-as-macros and having
[Bindable] be one of them.

>
>For the patch mentioned below, will you apply that to develop? Or do you
>want me to do that sometime tomorrow?

Now that you are a committer, you can do it yourself!

-Alex

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Just circling back to this: sure, I understand your point, Alex. I also am
usually all for addressing things in a central location.

I can see advantages either way, but had assumed that longer term it may be
advantageous to keep the AST/Typed AST more 'pure' and have 'Bindable' (and
possibly other forms of future metadata-driven) output variations be some
form of transformation at output. I am not only not a compiler expert, I'd
consider myself only slightly more than a novice (I did get my head into
the haxe compiler at one point a few years back, but ). So the way I think
about things is more in terms of analogies of things I do understand, which
may perhaps not be appropriate here.

I agree with what you pointed out for code implications and making future
maintenance/enhancements easier. I will give some thought to this in the
coming weeks, as maybe there is a way to refactor this to make things
easier all round, but still keep the AST 'pure'-ish. I can discuss with you
closer to the time, if so.

Re : "It is a convenience feature: the compiler could just report an error
saying you can't use [Bindable] on Objects."
I guess that is always another option. :)
[Bindable] implicit implementation was many times overused by some Flex
developers in the past, I was probably guilty of this myself in the early
days. But it is quite handy and quick sometimes, so long as you know the
implications of its use/abuse. And if it is taken away now I am pretty sure
sdk users will ask for it back ;)

For the patch mentioned below, will you apply that to develop? Or do you
want me to do that sometime tomorrow?
It sounded like you were ok with it, although had not tested it yet - fyi I
did run it by a few of the example apps and made sure the unit tests still
passed etc. I also made sure it correctly generated a swf with
flash.events.EventDispatcher instead of
org.apache.flex.events.EventDispatcher configured  - not for a FlexJS
actual binding test which I think may not work in some cases because of
coercion issues in the framework classes, but just to check that it handled
the config changes correctly and the swf output was valid when the base
class for the event dispatcher reverted to a 'native' player class.

cheers,
Greg

On Tue, Sep 6, 2016 at 4:49 PM, Alex Harui  wrote:

> I haven't tested the patch, looks reasonable.
>
> That said, the reason I tried hacking the AST in ASCompilationUnit was
> because I thought the "best" way would be to effectively fix up the source
> code as if it had been written properly in the first place.  IOW, this
> code effectively looks for source code that does:
>
> [Bindable]
> SomeClass extends Object
> {
> }
>
> And makes it look like:
>
> [Bindable]
> SomeClass extends EventDispatcher
> {
> }
>
> As you know, there are other patterns for static binding.  Or another way
> to think of it: if you do take the time to re-base your [Bindable] source
> code on EventDispatcher, none of this code in the compiler executes.  It
> is a convenience feature: the compiler could just report an error saying
> you can't use [Bindable] on Objects.
>
> I'm not a compiler expert, but back when Falcon only produced SWFs, I
> guess it seemed reasonable to leave the AST alone and generate modified
> output, but with FalconJX leveraging the AST, I'm concerned about work
> that means that future compiler developers will have to know that the AST
> doesn't go straight to JS or whatever the output is.  As we've seen, the
> JSDoc annotation was driven off the AST.  What else might we someday want
> to change in the AST "conversion" that will require us knowing about this
> code in ClassDirectiveProcessor?
>
> Anyway, again, I don't see any hurry to go back and look into
> re-implementing this [Bindable] handling in ASCompilationUnit.  At least
> we've recorded in the archives that there might be other ways to solve
> this problem.
>
> Thanks,
> -Alex
>
> On 9/5/16, 6:44 PM, "Greg Dove"  wrote:
>
> >I think I found  a solution for the dependency issue I mentioned.
> >The inclusion of "ValueChangeEvent" when not otherwise specified in the
> >project provided a useful clue here! (Otherwise I suspect I would not have
> >found this)
> >I need to do a bit more testing, but I expect to issue a related PR for a
> >change in ClassDirectiveProcessor before too long.
> >
> >On Mon, Sep 5, 2016 at 10:05 PM, Greg Dove  wrote:
> >
> >> Alex, I did some testing with a minimal project, I did not even have to
> >> try as-only, as SimpleApplication was sufficient. And yes, there is an
> >> issue if the dependency is not explicitly added somewhere. I will try to
> >> find a way to resolve this, otherwise the ASCompilationUnit code will
> >>need
> >> to go back.
> >> I had thought it might be useful to have the bindable implementation be
> >> more of any output variation than a manipulation of the AST. I had even
> >> wondered about longer term possibilities with such an 

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Alex, I did some testing with a minimal project, I did not even have to try
as-only, as SimpleApplication was sufficient. And yes, there is an issue if
the dependency is not explicitly added somewhere. I will try to find a way
to resolve this, otherwise the ASCompilationUnit code will need to go back.
I had thought it might be useful to have the bindable implementation be
more of any output variation than a manipulation of the AST. I had even
wondered about longer term possibilities with such an approach - e.g.
perhaps different binding implementation variations (e.g. as3 Signals
instead of events or something like that). I realize that this is not
something to think about seriously now. Plenty to do with things as they
are... was just thinking of possibilities for the future.

Anyhow, if I can't find a quick solution to add a specific dependency for
output in the swf without the ASCompilationUnit AST manipulation approach,
then that will need to go back (at least for now, anyway).
Perhaps this was the reason you did this in the first place? Was it when
the EventDispatcher base class for binding became non-native?
If you think its best to try and fix the original problems with the
original code in ASCompilationUnit , then perhaps that is the simplest
route for now. If so, I'd be keen to leave the other stuff I added for a
short time, but will happily remove the unnecessary parts once we can be
sure they never get branched into as a fallback (i.e. we can be sure the
ASCompilationUnit code catches all the 'extends' candidates). Let me know
what you think.

fyi I will be focusing on reflection work in whatever spare time I can find
this week, following on from where you got to earlier this year with that.
I will let you know where I get to later this week, I'm not sure if I will
have it finished this week or not.

cheers
Greg


On Sat, Sep 3, 2016 at 1:41 PM, Greg Dove  wrote:

> Sound great. Yes, switching it back on at any point should remain a quick
> fix option because it would simply make the other code act as a backstop.
> I will take a quick look on Monday to see if I can find any problems in
> small as-only projects where maybe the order of class definitions in the
> swf could be important with the current approach.  Sounds a bit like a
> theoretical edge case but you made me think about it.
> Have a nice weekend.
>
> -Greg
> [sent from my phone]
>
> On 3/09/2016 12:41 PM, "Alex Harui"  wrote:
>
>>
>>
>> On 9/2/16, 5:10 PM, "Greg Dove"  wrote:
>>
>> >Yes, that was one of the major changes. I moved it alongside the other
>> >implementation inside ClassDirectiveProcessor and was able to get more
>> >consistent results.
>> >I initially commented it out so I could get everything working using the
>> >implements IEventDispatcher approach - which is the more general approach
>> >that would work for all cases- in javascript, then added it back for both
>> >targets as a 2nd output variation in a later commit, and it went to
>> >ClassDirectorProcessor for swf.
>> >
>> >I was seeing 2 issues from the ASCompilationUnit implementation:
>> >1. It was not always applying where it should have been (so in cases
>> where
>> >it could have been 'extends EventDispatcher' it would sometimes fall
>> >through to the implements IEventDispatcher approach in
>> >ClassDIrectiveProcessor anyway). I suspect this was threading-related,
>> but
>> >I am not so familiar with threads.
>> >
>> >2. Less of an issue, it could also apply an EventDispatcher base class in
>> >static-only bindable cases, which is unnecessary, this I expect could
>> have
>> >been more easily fixed. I tried checking with hasModifier in the original
>> >code, but I think that might not be available yet, iirc that caused an
>> >error.
>> >
>> >So I moved everything to the ClassDirectiveProcessor, which had the other
>> >implementation of bindable support in any case. Sorry, I thought I had
>> >been
>> >clear about that.
>>
>> Well, you probably did explain it, but it probably didn't stick in my head
>> until we hit this last issue and I went looking for the code where I had a
>> vague memory of hacking a base class.  I still don't know the compiler
>> code so well that it is clear in my head what work should be done where.
>> It looks like the original attempt to deal with [Bindable] for SWF was
>> done in ClassDirectiveProcessor, but when I wanted to fix a bug in
>> FalconJX I decided to fix it by hacking the AST since that drives
>> everything in FalconJX.  The right answer may have been for me to move the
>> code from ClassDirectiveProcessor into ASCompilationUnit and use the
>> existing tests for needsEventDispatcher, then maybe we wouldn't have had
>> the two issues above.
>>
>> Anyway, I think we have recorded the possibility that AST hacking might be
>> a solution if we hit other problems.  I'm ok with leaving the code as is
>> until we hit another problem but feel free to keep digging if you 

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 9/2/16, 5:10 PM, "Greg Dove"  wrote:

>Yes, that was one of the major changes. I moved it alongside the other
>implementation inside ClassDirectiveProcessor and was able to get more
>consistent results.
>I initially commented it out so I could get everything working using the
>implements IEventDispatcher approach - which is the more general approach
>that would work for all cases- in javascript, then added it back for both
>targets as a 2nd output variation in a later commit, and it went to
>ClassDirectorProcessor for swf.
>
>I was seeing 2 issues from the ASCompilationUnit implementation:
>1. It was not always applying where it should have been (so in cases where
>it could have been 'extends EventDispatcher' it would sometimes fall
>through to the implements IEventDispatcher approach in
>ClassDIrectiveProcessor anyway). I suspect this was threading-related, but
>I am not so familiar with threads.
>
>2. Less of an issue, it could also apply an EventDispatcher base class in
>static-only bindable cases, which is unnecessary, this I expect could have
>been more easily fixed. I tried checking with hasModifier in the original
>code, but I think that might not be available yet, iirc that caused an
>error.
>
>So I moved everything to the ClassDirectiveProcessor, which had the other
>implementation of bindable support in any case. Sorry, I thought I had
>been
>clear about that.

Well, you probably did explain it, but it probably didn't stick in my head
until we hit this last issue and I went looking for the code where I had a
vague memory of hacking a base class.  I still don't know the compiler
code so well that it is clear in my head what work should be done where.
It looks like the original attempt to deal with [Bindable] for SWF was
done in ClassDirectiveProcessor, but when I wanted to fix a bug in
FalconJX I decided to fix it by hacking the AST since that drives
everything in FalconJX.  The right answer may have been for me to move the
code from ClassDirectiveProcessor into ASCompilationUnit and use the
existing tests for needsEventDispatcher, then maybe we wouldn't have had
the two issues above.

Anyway, I think we have recorded the possibility that AST hacking might be
a solution if we hit other problems.  I'm ok with leaving the code as is
until we hit another problem but feel free to keep digging if you want.

Thanks,
-Alex

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Yes, that was one of the major changes. I moved it alongside the other
implementation inside ClassDirectiveProcessor and was able to get more
consistent results.
I initially commented it out so I could get everything working using the
implements IEventDispatcher approach - which is the more general approach
that would work for all cases- in javascript, then added it back for both
targets as a 2nd output variation in a later commit, and it went to
ClassDirectorProcessor for swf.

I was seeing 2 issues from the ASCompilationUnit implementation:
1. It was not always applying where it should have been (so in cases where
it could have been 'extends EventDispatcher' it would sometimes fall
through to the implements IEventDispatcher approach in
ClassDIrectiveProcessor anyway). I suspect this was threading-related, but
I am not so familiar with threads.

2. Less of an issue, it could also apply an EventDispatcher base class in
static-only bindable cases, which is unnecessary, this I expect could have
been more easily fixed. I tried checking with hasModifier in the original
code, but I think that might not be available yet, iirc that caused an
error.

So I moved everything to the ClassDirectiveProcessor, which had the other
implementation of bindable support in any case. Sorry, I thought I had been
clear about that.

cheers
Greg


On Sat, Sep 3, 2016 at 11:55 AM, Alex Harui  wrote:

>
>
> On 9/2/16, 4:30 PM, "Greg Dove"  wrote:
>
> >"In looking at the change in Falcon, it appears that the patch was
> >required
> >because the resolveBaseClass does not resolve to EventDispatcher.  Did you
> >look into trying to get resolveBaseClass to resolve to EventDispatcher.
> >I'm wondering if there will be other issues related to that."
> >
> >The change is more at the output stage rather than hacking the original
> >AST
> >to do that now. You know this far better than I do, but I don't *think*
> >this should cause an issue in js because of the way the framework classes
> >are always avalalable, but just thinking about it, perhaps for a simple AS
> >project with a couple of Bindable classes, if the implicit implementation
> >is created this may cause an issue in swf, because the baseclass
> >EventDispatcher is now non-native - if the dependency is not addressed
> >explicitly elsewhere in the swf - is that what you mean? I haven't tried
> >anything like this, but I can check this first thing on Monday my time.
>
> In looking more closely at these changes, one of the changes removed code
> from ASCompilationUnit that set the base class to EventDispatcher.  I
> hadn't realized that code wasn't replaced elsewhere, but it seems like
> hacking the AST to set the base class would have also fixed the last two
> issues (the missing goog.require and the missing @extends).  So now I'm
> more curious about why you chose to move the logic to
> ClassDirectiveProcessor, and that further makes me wonder if we just
> haven't noticed some other ramification of not hacking the AST.
>
> We can continue this on Monday, no hurry.
>
> Thanks,
> -Alex
>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 9/2/16, 4:30 PM, "Greg Dove"  wrote:

>"In looking at the change in Falcon, it appears that the patch was
>required
>because the resolveBaseClass does not resolve to EventDispatcher.  Did you
>look into trying to get resolveBaseClass to resolve to EventDispatcher.
>I'm wondering if there will be other issues related to that."
>
>The change is more at the output stage rather than hacking the original
>AST
>to do that now. You know this far better than I do, but I don't *think*
>this should cause an issue in js because of the way the framework classes
>are always avalalable, but just thinking about it, perhaps for a simple AS
>project with a couple of Bindable classes, if the implicit implementation
>is created this may cause an issue in swf, because the baseclass
>EventDispatcher is now non-native - if the dependency is not addressed
>explicitly elsewhere in the swf - is that what you mean? I haven't tried
>anything like this, but I can check this first thing on Monday my time.

In looking more closely at these changes, one of the changes removed code
from ASCompilationUnit that set the base class to EventDispatcher.  I
hadn't realized that code wasn't replaced elsewhere, but it seems like
hacking the AST to set the base class would have also fixed the last two
issues (the missing goog.require and the missing @extends).  So now I'm
more curious about why you chose to move the logic to
ClassDirectiveProcessor, and that further makes me wonder if we just
haven't noticed some other ramification of not hacking the AST.

We can continue this on Monday, no hurry.

Thanks,
-Alex

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

"In looking at the change in Falcon, it appears that the patch was required
because the resolveBaseClass does not resolve to EventDispatcher.  Did you
look into trying to get resolveBaseClass to resolve to EventDispatcher.
I'm wondering if there will be other issues related to that."

The change is more at the output stage rather than hacking the original AST
to do that now. You know this far better than I do, but I don't *think*
this should cause an issue in js because of the way the framework classes
are always avalalable, but just thinking about it, perhaps for a simple AS
project with a couple of Bindable classes, if the implicit implementation
is created this may cause an issue in swf, because the baseclass
EventDispatcher is now non-native - if the dependency is not addressed
explicitly elsewhere in the swf - is that what you mean? I haven't tried
anything like this, but I can check this first thing on Monday my time.


"I'll see if I can reproduce."

I think there was an example of this in the manualtests commit history of
MyIntiialView




On Sat, Sep 3, 2016 at 11:14 AM, Alex Harui  wrote:

>
>
> On 9/2/16, 3:26 PM, "Greg Dove"  wrote:
>
> >Alex, I believe the last PRs I made across falcon and asjs address the
> >various recent issues we discussed.
>
> Hi Greg, thanks for sticking with it.
>
> In looking at the change in Falcon, it appears that the patch was required
> because the resolveBaseClass does not resolve to EventDispatcher.  Did you
> look into trying to get resolveBaseClass to resolve to EventDispatcher.
> I'm wondering if there will be other issues related to that.
>
> >
> >One additional (strange) thing I observed (partly because I was using a
> >plain text editor at one point, without xml hinting) is that you can get a
> >swf with invalid bytecode (stack overflow or underflow) by having bad xml
> >in the mxml.
>
> I'll see if I can reproduce.
>
> -Alex
>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 9/2/16, 3:26 PM, "Greg Dove"  wrote:

>Alex, I believe the last PRs I made across falcon and asjs address the
>various recent issues we discussed.

Hi Greg, thanks for sticking with it.

In looking at the change in Falcon, it appears that the patch was required
because the resolveBaseClass does not resolve to EventDispatcher.  Did you
look into trying to get resolveBaseClass to resolve to EventDispatcher.
I'm wondering if there will be other issues related to that.

>
>One additional (strange) thing I observed (partly because I was using a
>plain text editor at one point, without xml hinting) is that you can get a
>swf with invalid bytecode (stack overflow or underflow) by having bad xml
>in the mxml.

I'll see if I can reproduce.

-Alex

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Alex, I believe the last PRs I made across falcon and asjs address the
various recent issues we discussed.

One additional (strange) thing I observed (partly because I was using a
plain text editor at one point, without xml hinting) is that you can get a
swf with invalid bytecode (stack overflow or underflow) by having bad xml
in the mxml.

I had a stray '-->' at one point in the mxml without a matching open
comment tag and there was no compiler error. The resulting swf was bad (but
the js output still seemed fine). The regular flex 4.x compiler gives an
error in this case, so this is something else that needs to be looked at -
I can come back to see if I can figure that out it if no-one else does, but
I am more keen to work on some reflection stuff next over the coming week
(I have something in mind that I think will help make framework development
work easier in general).

cheers
Greg


On Sat, Sep 3, 2016 at 5:15 AM, Greg Dove  wrote:

> Thanks! I was hoping it was something like that. I will add that now and
> test.
> I did look through the google closure docs for the annotations with the
> various outputs, but mostly followed whatever leads were already in the
> code and I did not look at the class level stuff I guess.
>
>  (I actually had a lot of head-scratching on release output at one point
> when I was working on the earlier stuff with the static bindable var output
> - until I found Josh's comment elsewhere in the code about using the
> 'deprecated' @expose instead of @export for static accessors)
>
>
> On Sat, Sep 3, 2016 at 2:52 AM, Alex Harui  wrote:
>
>>
>>
>> On 9/1/16, 11:40 PM, "Greg Dove"  wrote:
>>
>> >Took me a little while to get to this...
>> >
>> >Actually, I am really confused here. I don't have a real 'fix', but I
>> >understand what is causing it after chasing a few wild geese for a while.
>> >It seems the remove-circulars setting is the primary cause of this
>> problem
>> >- removing that setting restores all the goog.requires stuff (which I
>> >*thought* I had already supported in the output), and after this js
>> >release
>> >mode seems fine. Is there any known bug here with remove-circulars? Or do
>> >I
>> >need to do something extra in the output to make it compatible with
>> >remove-circulars ?
>>
>> I forgot that it may not be as simple as adding goog.require.  I just took
>> another look and saw that the constructor jsdoc is missing the @extends
>> (and/or @implements) directive which I think Google Closure Compiler uses,
>> but also the remove-circulars uses it to make sure that goog.requires for
>> base classes do not get removed.
>>
>> Hope that gets things working,
>> -Alex
>>
>>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Thanks! I was hoping it was something like that. I will add that now and
test.
I did look through the google closure docs for the annotations with the
various outputs, but mostly followed whatever leads were already in the
code and I did not look at the class level stuff I guess.

 (I actually had a lot of head-scratching on release output at one point
when I was working on the earlier stuff with the static bindable var output
- until I found Josh's comment elsewhere in the code about using the
'deprecated' @expose instead of @export for static accessors)


On Sat, Sep 3, 2016 at 2:52 AM, Alex Harui  wrote:

>
>
> On 9/1/16, 11:40 PM, "Greg Dove"  wrote:
>
> >Took me a little while to get to this...
> >
> >Actually, I am really confused here. I don't have a real 'fix', but I
> >understand what is causing it after chasing a few wild geese for a while.
> >It seems the remove-circulars setting is the primary cause of this problem
> >- removing that setting restores all the goog.requires stuff (which I
> >*thought* I had already supported in the output), and after this js
> >release
> >mode seems fine. Is there any known bug here with remove-circulars? Or do
> >I
> >need to do something extra in the output to make it compatible with
> >remove-circulars ?
>
> I forgot that it may not be as simple as adding goog.require.  I just took
> another look and saw that the constructor jsdoc is missing the @extends
> (and/or @implements) directive which I think Google Closure Compiler uses,
> but also the remove-circulars uses it to make sure that goog.requires for
> base classes do not get removed.
>
> Hope that gets things working,
> -Alex
>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 9/1/16, 11:40 PM, "Greg Dove"  wrote:

>Took me a little while to get to this...
>
>Actually, I am really confused here. I don't have a real 'fix', but I
>understand what is causing it after chasing a few wild geese for a while.
>It seems the remove-circulars setting is the primary cause of this problem
>- removing that setting restores all the goog.requires stuff (which I
>*thought* I had already supported in the output), and after this js
>release
>mode seems fine. Is there any known bug here with remove-circulars? Or do
>I
>need to do something extra in the output to make it compatible with
>remove-circulars ?

I forgot that it may not be as simple as adding goog.require.  I just took
another look and saw that the constructor jsdoc is missing the @extends
(and/or @implements) directive which I think Google Closure Compiler uses,
but also the remove-circulars uses it to make sure that goog.requires for
base classes do not get removed.

Hope that gets things working,
-Alex

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Took me a little while to get to this...

Actually, I am really confused here. I don't have a real 'fix', but I
understand what is causing it after chasing a few wild geese for a while.
It seems the remove-circulars setting is the primary cause of this problem
- removing that setting restores all the goog.requires stuff (which I
*thought* I had already supported in the output), and after this js release
mode seems fine. Is there any known bug here with remove-circulars? Or do I
need to do something extra in the output to make it compatible with
remove-circulars ?


On Fri, Sep 2, 2016 at 2:25 PM, Greg Dove  wrote:

> ah. I was just about to circle back to this stuff. Thanks for picking that
> up... yes I will fix that, my mistake!
>
>
> On Fri, Sep 2, 2016 at 2:23 PM, Alex Harui  wrote:
>
>>
>>
>> On 9/1/16, 8:15 AM, "Alex Harui"  wrote:
>>
>> >I will take a look.
>> >
>> >Thanks for trying it.
>>
>> OK, I figured out why the release version is not working.  The output for
>> InstanceTimer (for example) which got re-based to inherit from
>> EventDispatcher, is missing the goog.require for EventDispatcher.  This
>> fools the Google Closure Compiler and it does not emit EventDispatcher
>> before InstanceTimer so the prototype never gets set properly and thus
>> dispatchEvent is missing.  It works in js-debug because other code happens
>> to load EventDispatcher first.
>>
>> Do you want to make the fix to the compiler?
>>
>> Thanks,
>> -Alex
>>
>>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

ah. I was just about to circle back to this stuff. Thanks for picking that
up... yes I will fix that, my mistake!


On Fri, Sep 2, 2016 at 2:23 PM, Alex Harui  wrote:

>
>
> On 9/1/16, 8:15 AM, "Alex Harui"  wrote:
>
> >I will take a look.
> >
> >Thanks for trying it.
>
> OK, I figured out why the release version is not working.  The output for
> InstanceTimer (for example) which got re-based to inherit from
> EventDispatcher, is missing the goog.require for EventDispatcher.  This
> fools the Google Closure Compiler and it does not emit EventDispatcher
> before InstanceTimer so the prototype never gets set properly and thus
> dispatchEvent is missing.  It works in js-debug because other code happens
> to load EventDispatcher first.
>
> Do you want to make the fix to the compiler?
>
> Thanks,
> -Alex
>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 9/1/16, 8:15 AM, "Alex Harui"  wrote:

>I will take a look.
>
>Thanks for trying it.

OK, I figured out why the release version is not working.  The output for
InstanceTimer (for example) which got re-based to inherit from
EventDispatcher, is missing the goog.require for EventDispatcher.  This
fools the Google Closure Compiler and it does not emit EventDispatcher
before InstanceTimer so the prototype never gets set properly and thus
dispatchEvent is missing.  It works in js-debug because other code happens
to load EventDispatcher first.

Do you want to make the fix to the compiler?

Thanks,
-Alex

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

I will take a look.

Thanks for trying it.
-Alex

On 9/1/16, 1:51 AM, "Greg Dove"  wrote:

>Alex, here's what I tried:
>
>   COMPILE::JS
>public class EventDispatcher extends goog.events.EventTarget implements
>IEventDispatcher
>{
>private var _target:IEventDispatcher;
>public function EventDispatcher(target:IEventDispatcher = null)
>{
>_target = target || this;
>}
>
>public function hasEventListener(type:String):Boolean
>{
>return goog.events.hasListener(this, type);
>}
>override public function dispatchEvent(event:Object):Boolean
>{
>try
>{
>//we get quite a few string events here, "initialize" etc
>//so this general approach doesn't work:
>//event.target = _target;
>if (event is String) event = new Event(event as String,_target);
>else if (event.target != undefined) event.target = _target;
>return super.dispatchEvent(event);
>}
>catch (e:Error)
>{
>if (e.name != "stopImmediatePropagation")
>throw e;
>}
>return false;
>}
>}
>
>
>This seemed to work in js-debug, but I saw issues (see below) in some code
>in release mode, I didn't get to the bottom of that yet, sorry.
>I had not seen these with the original version:
>Uncaught TypeError: this.dispatchEvent is not a function
>
>
>On Thu, Sep 1, 2016 at 6:20 PM, Greg Dove  wrote:
>
>> yeah, it's 6pm here now, I am breaking for dinner. Will try this evening
>> and report back here
>>
>> On Thu, Sep 1, 2016 at 6:16 PM, Alex Harui  wrote:
>>
>>>
>>>
>>> On 8/31/16, 11:03 PM, "Greg Dove"  wrote:
>>>
>>> >In looking at the Google code, it appears that all we need to do in
>>>our
>>> >EventDispatcher.dispatchEvent override is set the event.target on the
>>> >event object to the wrapper.  Do you see the same thing?
>>> >
>>> >I didn't try that, but yes I do see that now. well spotted! :)
>>> >that sounds good if all our events are descendants of
>>>goog.events.Event
>>>
>>> Do you have time to try it?  I can try tomorrow (for me) if you don't
>>>have
>>> time.
>>>
>>> Thanks,
>>> -Alex
>>>
>>>
>>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Alex, here's what I tried:

   COMPILE::JS
public class EventDispatcher extends goog.events.EventTarget implements
IEventDispatcher
{
private var _target:IEventDispatcher;
public function EventDispatcher(target:IEventDispatcher = null)
{
_target = target || this;
}

public function hasEventListener(type:String):Boolean
{
return goog.events.hasListener(this, type);
}
override public function dispatchEvent(event:Object):Boolean
{
try
{
//we get quite a few string events here, "initialize" etc
//so this general approach doesn't work:
//event.target = _target;
if (event is String) event = new Event(event as String,_target);
else if (event.target != undefined) event.target = _target;
return super.dispatchEvent(event);
}
catch (e:Error)
{
if (e.name != "stopImmediatePropagation")
throw e;
}
return false;
}
}


This seemed to work in js-debug, but I saw issues (see below) in some code
in release mode, I didn't get to the bottom of that yet, sorry.
I had not seen these with the original version:
Uncaught TypeError: this.dispatchEvent is not a function


On Thu, Sep 1, 2016 at 6:20 PM, Greg Dove  wrote:

> yeah, it's 6pm here now, I am breaking for dinner. Will try this evening
> and report back here
>
> On Thu, Sep 1, 2016 at 6:16 PM, Alex Harui  wrote:
>
>>
>>
>> On 8/31/16, 11:03 PM, "Greg Dove"  wrote:
>>
>> >In looking at the Google code, it appears that all we need to do in our
>> >EventDispatcher.dispatchEvent override is set the event.target on the
>> >event object to the wrapper.  Do you see the same thing?
>> >
>> >I didn't try that, but yes I do see that now. well spotted! :)
>> >that sounds good if all our events are descendants of goog.events.Event
>>
>> Do you have time to try it?  I can try tomorrow (for me) if you don't have
>> time.
>>
>> Thanks,
>> -Alex
>>
>>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

yeah, it's 6pm here now, I am breaking for dinner. Will try this evening
and report back here

On Thu, Sep 1, 2016 at 6:16 PM, Alex Harui  wrote:

>
>
> On 8/31/16, 11:03 PM, "Greg Dove"  wrote:
>
> >In looking at the Google code, it appears that all we need to do in our
> >EventDispatcher.dispatchEvent override is set the event.target on the
> >event object to the wrapper.  Do you see the same thing?
> >
> >I didn't try that, but yes I do see that now. well spotted! :)
> >that sounds good if all our events are descendants of goog.events.Event
>
> Do you have time to try it?  I can try tomorrow (for me) if you don't have
> time.
>
> Thanks,
> -Alex
>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 8/31/16, 11:03 PM, "Greg Dove"  wrote:

>In looking at the Google code, it appears that all we need to do in our
>EventDispatcher.dispatchEvent override is set the event.target on the
>event object to the wrapper.  Do you see the same thing?
>
>I didn't try that, but yes I do see that now. well spotted! :)
>that sounds good if all our events are descendants of goog.events.Event

Do you have time to try it?  I can try tomorrow (for me) if you don't have
time.

Thanks,
-Alex

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

In looking at the Google code, it appears that all we need to do in our
EventDispatcher.dispatchEvent override is set the event.target on the
event object to the wrapper.  Do you see the same thing?

I didn't try that, but yes I do see that now. well spotted! :)
that sounds good if all our events are descendants of goog.events.Event

I saw all the other parts except for this:
e.target = e.target || target;




On Thu, Sep 1, 2016 at 5:44 PM, Alex Harui  wrote:

>
>
> On 8/31/16, 9:51 PM, "Greg Dove"  wrote:
>
> >Yeah, I guess that is not 'simple' in terms of an example but it was
> >easier
> >to show it with what was already there.
> >
> > "I thought that folks who created custom IEventDispatchers without
> >extending
> >EventDispatcher wrapped an EventDispatcher and passed in a reference to
> >the instance to that EventDispatcher."
> >
> >yep, I am definitely one of those folks too :). That's what I am doing.
> >
> >"Are you saying it didn't work atall in JS?"
> >
> >I did not see it work, and based on the eventtarget code, I can't see how
> >it can.
>
> Hmm, looking at this case again, I agree that it couldn't work.  I must
> have had my head on sideways that day.
>
> The exception we hit in the test case is because we've set the
> actualEventTarget_ to the wrapper instead of the wrapped EventDispatcher,
> which causes the code to look in the wrong place for the fireListeners
> method.  But we don't really want to do that at all.  It doesn't matter
> which object manages the list of listeners to call.  t think all we really
> want is to set the event.target to be the wrapper instead of the wrapped
> EventDispatcher.
>
> In looking at the Google code, it appears that all we need to do in our
> EventDispatcher.dispatchEvent override is set the event.target on the
> event object to the wrapper.  Do you see the same thing?  Then we don't
> need the other patches to Google's code you have proposed.
>
> Of course, I could be wrong.
>
> Thanks,
> -Alex
>
>

Re: AW: AW: AW: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 8/31/16, 10:27 PM, "Christofer Dutz"  wrote:

>Hi Alex,
>
>I only parametrized the options that needed swithing in the build. If a
>seeing was set to the same value everywhere, I just our that value in the
>template.
>
>Too new it seemed as if the new option was only needed in a few builds,
>that's why I suggested adding the option to the mojo.

IMO, we need to set these for every compile.  I would put it in
flex-config-template.xml (and the other templates).  What Maven-related
files need to be changed to have the equivalent effect.

-Alex

PS:  Have you looked at the nightly build source package?  We still need a
thumbs up from at least one more PMC member before cutting RCs.  If we
don't get them soon, we may not make Sept 8.  I would rather not spend the
time to create RCs only to have them declared faulty and have to do it
again.

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 8/31/16, 9:51 PM, "Greg Dove"  wrote:

>Yeah, I guess that is not 'simple' in terms of an example but it was
>easier
>to show it with what was already there.
>
> "I thought that folks who created custom IEventDispatchers without
>extending
>EventDispatcher wrapped an EventDispatcher and passed in a reference to
>the instance to that EventDispatcher."
>
>yep, I am definitely one of those folks too :). That's what I am doing.
>
>"Are you saying it didn't work atall in JS?"
>
>I did not see it work, and based on the eventtarget code, I can't see how
>it can.

Hmm, looking at this case again, I agree that it couldn't work.  I must
have had my head on sideways that day.

The exception we hit in the test case is because we've set the
actualEventTarget_ to the wrapper instead of the wrapped EventDispatcher,
which causes the code to look in the wrong place for the fireListeners
method.  But we don't really want to do that at all.  It doesn't matter
which object manages the list of listeners to call.  t think all we really
want is to set the event.target to be the wrapper instead of the wrapped
EventDispatcher.

In looking at the Google code, it appears that all we need to do in our
EventDispatcher.dispatchEvent override is set the event.target on the
event object to the wrapper.  Do you see the same thing?  Then we don't
need the other patches to Google's code you have proposed.

Of course, I could be wrong.

Thanks,
-Alex

AW: AW: AW: [FlexJX][Falcon] Binding support fixes/improvements

[Christofer Dutz]

Hi Alex,

I only parametrized the options that needed swithing in the build. If a seeing 
was set to the same value everywhere, I just our that value in the template.

Too new it seemed as if the new option was only needed in a few builds, that's 
why I suggested adding the option to the mojo.

Chris



Von meinem Samsung Galaxy Smartphone gesendet.


 Ursprüngliche Nachricht 
Von: Alex Harui <aha...@adobe.com>
Datum: 31.08.16 18:02 (GMT+01:00)
An: dev@flex.apache.org
Betreff: Re: AW: AW: [FlexJX][Falcon] Binding support fixes/improvements

Chris,

I just looked through this code.  It appears that there are several
compiler options that are not listed in these files.  Should they all be
there?  Most of the missing ones are defaults set in flex-config.xml.  Of
the three Greg mentioned below only one isn't currently in flex-config.xml
and I would recommend just adding it there.  Then I think the java files
wouldn't "have to" change unless you want this code to support all
configuration options.

Thoughts?
-Alex

On 8/31/16, 1:32 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:

>Hi Greg,
>
>
>Well in the flexjs-maven-plugin the class BaseMojo and all classes
>derived from that for example define a whole bunch of properties like
>this (In CompileAppMojo):
>
>@Parameter(defaultValue = "false")
>protected boolean removeCirculars;
>
>So it defines a boolean config option "removeCirculars" which can be used
>in the pom.xml, or if missing, it uses a default of "false". In order to
>get the property into the compiler configuration file, for example you
>would need to add the property in the nearest mojo class, and make sure
>that property is added to the Velocity context:
>
>@Override
>protected VelocityContext getVelocityContext() throws
>MojoExecutionException {
>VelocityContext context = super.getVelocityContext();
>context.put("removeCirculars", removeCirculars);
>return context;
>}
>
>This makes it possible to access the property in the Velocity template I
>use to generate the compiler config file
>(compile-app-javascript-config.xml):
>
>
>$removeCirculars
>
>But you could just tell me which config option you deed in which
>compilation and I could add the option. I just thought documenting this
>use-case would be a good thing to do ;-)
>
>
>If you also tell me which examples need the option, we could then adjust
>the pom.xml for those projects.
>
>
>Chris
>
>
>
>
>
>
>Von: Greg Dove <greg.d...@gmail.com>
>Gesendet: Mittwoch, 31. August 2016 09:50:08
>An: dev@flex.apache.org
>Betreff: Re: AW: [FlexJX][Falcon] Binding support fixes/improvements
>
>Chris I will try to figure out tomorrow  how to do this type of thing for
>maven also. I don't recall seeing the other compiler config settings in
>pom.xml files when I looked for them so I must have been looking in the
>wrong place.
>
>-Greg
>[sent from my phone]
>
>On 31/08/2016 6:26 PM, "Christofer Dutz" <christofer.d...@c-ware.de>
>wrote:
>
>> What changes are needed fire the examples. Please keep in mind that they
>> also have to be applied to the Maven build to prevent it from diverging
>> from the ant one.
>>
>> Chris
>>
>>
>>
>> Von meinem Samsung Galaxy Smartphone gesendet.
>>
>>
>>  Ursprüngliche Nachricht 
>> Von: Greg Dove <greg.d...@gmail.com>
>> Datum: 30.08.16 22:12 (GMT+01:00)
>> An: dev@flex.apache.org
>> Betreff: Re: [FlexJX][Falcon] Binding support fixes/improvements
>>
>> Thanks for the feedback Alex.
>> I had also received encouragement from Justin a long time ago to
>> contribute, I'm happy that I finally got a chance to do so.
>>
>> tbh I had not even looked inside manual tests folder yet (there's a lot
>>in
>> there!), but that definitely sounds like a better place for that
>>example,
>> it really is a 'manual test'.
>>
>> it might require the addition of :
>>
>> > value="-compiler.binding-event-handler-interface=org.apache.flex.events.
>> IEventDispatcher"
>> />
>> > value="-compiler.binding-event-handler-class=org.apache.flex.events.
>> EventDispatcher"
>> />
>> >
>>value="-compiler.binding-event-handler-event=org.apache.flex.events.Event
>>"
>> />
>>
>> to the build_example ant file targets, if you didn't already add it
>>
>> In terms of my sleeves, I hope to find something more up there within
>>the
>> next couple of weeks. My regular client work is in a bit

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Yeah, I guess that is not 'simple' in terms of an example but it was easier
to show it with what was already there.

 "I thought that folks who created custom IEventDispatchers without
extending
EventDispatcher wrapped an EventDispatcher and passed in a reference to
the instance to that EventDispatcher."

yep, I am definitely one of those folks too :). That's what I am doing.

"Are you saying it didn't work atall in JS?"

I did not see it work, and based on the eventtarget code, I can't see how
it can.
I don't actually know what the intent of their setTargetForTesting is so I
am not sure if it is a bug
or whether they only ever intended one EventTarget to be manipulating
another. The typing in their
code is Object, not goog.events.EventTarget for that method's argument, so
it might even be a bug on their side.

I made another minor change to what I had against eventtarget, which avoids
a little branching - if you replace your library copy of eventtarget.js
with this [1] you should
be able to change the setTargetForTesting call to
setTargetForTesting(target,true) and the hack can be avoided.

1.
https://raw.githubusercontent.com/greg-dove/closure-library/342fa762984b10e53ebe9fcb906b7af813edb739/closure/goog/events/eventtarget.js


On Thu, Sep 1, 2016 at 4:41 PM, Alex Harui  wrote:

> Nevermind, didn't see the PR.  Thanks for creating it.  Looking into it.
>
> On 8/31/16, 9:23 PM, "Alex Harui"  wrote:
>
> >Before we try to patch Closure Library, I would still like to examine a
> >simple test case.  I think it would help me understand the problem.  I
> >thought that folks who created custom IEventDispatchers without extending
> >EventDispatcher wrapped an EventDispatcher and passed in a reference to
> >the instance to that EventDispatcher.  Are you saying it didn't work at
> >all in JS?  Or just in some scenario?
> >
> >Thanks,
> >-Alex
> >
> >On 8/31/16, 4:47 PM, "Greg Dove"  wrote:
> >
> >>"I guess we need something on goog's EventTarget that is more
> >>setExternalTarget and that is only used for the event.target , not for
> >>the
> >>fireListeners call. "
> >>
> >>This type of change to their eventtarget.js works [1] and all that is
> >>needed is a change to setTargetForTesting(target) to be
> >>setTargetForTesting(target,true) in our constructor. Then that hack I
> >>added
> >>is no longer needed.
> >>
> >>I have not issued any request against closure lib there yet, but can do
> >>so
> >>if you think it is best (I don't know how it will be received). I'm not
> >>entirely comfortable doing this on behalf of Apache Flex, so would prefer
> >>if someone on the team did it.
> >>
> >>I can't see another simpler way around this (which doesn't mean there
> >>isn't
> >>one!). I definitely didn't want to put that method in the interface
> >>because
> >>it would deviate from flash.
> >>
> >>
> >>
> >>1.
> >>https://github.com/greg-dove/closure-library/commit/
> 6be3161f02cf327a0dc1a
> >>3
> >>3f085f0531d2993b4e
> >>
> >>
> >>
> >>On Thu, Sep 1, 2016 at 10:03 AM, Greg Dove  wrote:
> >>
> >>>  Alex, I just issued a PR that lets you easily see the problem (along
> >>>with
> >>> a fix for ant script for the manual test).
> >>>
> >>> I had a quick look inside eventtarget.js and it seems pretty clear to
> >>>me:
> >>>
> >>>
> >>>https://github.com/google/closure-library/blob/master/
> closure/goog/event
> >>>s
> >>>/
> >>> eventtarget.js#L349
> >>>
> >>> it is calling currentTarget.fireListeners and in the most basic case
> >>>for
> >>> proxy event dispatching, this is the same as the 'targetForTesting'
> >>>which
> >>> requires that fireListeners is implemented on the alternate target.
> >>> when a subclass inherits EventDispatcher, currentTarget will always
> >>> be 'this' and so the same instance EventTarget's fireListeners method
> >>>is
> >>> called directly.
> >>>
> >>> all the other variables and functions are referenced via 'this' which
> >>> would correctly resolve inside the proxy EventDispatcher instance,
> >>>although
> >>> they would all obviously be inherited if the class extends the flexjs
> >>> EventDispatcher.
> >>>
> >>> I guess we need something on goog's EventTarget that is more
> >>> setExternalTarget and that is only used for the event.target , not for
> >>>the
> >>> fireListeners call.
> >>>
> >>>
> >>>
> >>> On Thu, Sep 1, 2016 at 3:51 AM, Alex Harui  wrote:
> >>>
> 
> 
>  On 8/31/16, 12:43 AM, "Greg Dove"  wrote:
> 
>  >I observed that issue when implementing  IEventdispatcher i.e. when
> the
>  >EventDispatcher constructor has an IEventDispatcher argument - so not
> for
>  >statics. This is not seen when extending EventDispatcher, but in that
>  case
>  >the subclass would presumably inherit that method from goog
> EventTarget.
>  >So
>  >that setCurrentTarget method in the constructor did not seem to be
> the
>  

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

Nevermind, didn't see the PR.  Thanks for creating it.  Looking into it.

On 8/31/16, 9:23 PM, "Alex Harui"  wrote:

>Before we try to patch Closure Library, I would still like to examine a
>simple test case.  I think it would help me understand the problem.  I
>thought that folks who created custom IEventDispatchers without extending
>EventDispatcher wrapped an EventDispatcher and passed in a reference to
>the instance to that EventDispatcher.  Are you saying it didn't work at
>all in JS?  Or just in some scenario?
>
>Thanks,
>-Alex
>
>On 8/31/16, 4:47 PM, "Greg Dove"  wrote:
>
>>"I guess we need something on goog's EventTarget that is more
>>setExternalTarget and that is only used for the event.target , not for
>>the
>>fireListeners call. "
>>
>>This type of change to their eventtarget.js works [1] and all that is
>>needed is a change to setTargetForTesting(target) to be
>>setTargetForTesting(target,true) in our constructor. Then that hack I
>>added
>>is no longer needed.
>>
>>I have not issued any request against closure lib there yet, but can do
>>so
>>if you think it is best (I don't know how it will be received). I'm not
>>entirely comfortable doing this on behalf of Apache Flex, so would prefer
>>if someone on the team did it.
>>
>>I can't see another simpler way around this (which doesn't mean there
>>isn't
>>one!). I definitely didn't want to put that method in the interface
>>because
>>it would deviate from flash.
>>
>>
>>
>>1.
>>https://github.com/greg-dove/closure-library/commit/6be3161f02cf327a0dc1a
>>3
>>3f085f0531d2993b4e
>>
>>
>>
>>On Thu, Sep 1, 2016 at 10:03 AM, Greg Dove  wrote:
>>
>>>  Alex, I just issued a PR that lets you easily see the problem (along
>>>with
>>> a fix for ant script for the manual test).
>>>
>>> I had a quick look inside eventtarget.js and it seems pretty clear to
>>>me:
>>>
>>> 
>>>https://github.com/google/closure-library/blob/master/closure/goog/event
>>>s
>>>/
>>> eventtarget.js#L349
>>>
>>> it is calling currentTarget.fireListeners and in the most basic case
>>>for
>>> proxy event dispatching, this is the same as the 'targetForTesting'
>>>which
>>> requires that fireListeners is implemented on the alternate target.
>>> when a subclass inherits EventDispatcher, currentTarget will always
>>> be 'this' and so the same instance EventTarget's fireListeners method
>>>is
>>> called directly.
>>>
>>> all the other variables and functions are referenced via 'this' which
>>> would correctly resolve inside the proxy EventDispatcher instance,
>>>although
>>> they would all obviously be inherited if the class extends the flexjs
>>> EventDispatcher.
>>>
>>> I guess we need something on goog's EventTarget that is more
>>> setExternalTarget and that is only used for the event.target , not for
>>>the
>>> fireListeners call.
>>>
>>>
>>>
>>> On Thu, Sep 1, 2016 at 3:51 AM, Alex Harui  wrote:
>>>


 On 8/31/16, 12:43 AM, "Greg Dove"  wrote:

 >I observed that issue when implementing  IEventdispatcher i.e. when
the
 >EventDispatcher constructor has an IEventDispatcher argument - so not
for
 >statics. This is not seen when extending EventDispatcher, but in that
 case
 >the subclass would presumably inherit that method from goog
EventTarget.
 >So
 >that setCurrentTarget method in the constructor did not seem to be
the
 >complete answer here... that extra hack in the constructor just got
 things
 >working for nowit works as is but I don't like it.

 Interesting.  Do you have a simple test case we can look at?  Looking
at
 the EventTarget code, I would think there would be other functions and
 variables that need propagation.

 Thanks,
 -Alex


>>>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

Before we try to patch Closure Library, I would still like to examine a
simple test case.  I think it would help me understand the problem.  I
thought that folks who created custom IEventDispatchers without extending
EventDispatcher wrapped an EventDispatcher and passed in a reference to
the instance to that EventDispatcher.  Are you saying it didn't work at
all in JS?  Or just in some scenario?

Thanks,
-Alex

On 8/31/16, 4:47 PM, "Greg Dove"  wrote:

>"I guess we need something on goog's EventTarget that is more
>setExternalTarget and that is only used for the event.target , not for the
>fireListeners call. "
>
>This type of change to their eventtarget.js works [1] and all that is
>needed is a change to setTargetForTesting(target) to be
>setTargetForTesting(target,true) in our constructor. Then that hack I
>added
>is no longer needed.
>
>I have not issued any request against closure lib there yet, but can do so
>if you think it is best (I don't know how it will be received). I'm not
>entirely comfortable doing this on behalf of Apache Flex, so would prefer
>if someone on the team did it.
>
>I can't see another simpler way around this (which doesn't mean there
>isn't
>one!). I definitely didn't want to put that method in the interface
>because
>it would deviate from flash.
>
>
>
>1.
>https://github.com/greg-dove/closure-library/commit/6be3161f02cf327a0dc1a3
>3f085f0531d2993b4e
>
>
>
>On Thu, Sep 1, 2016 at 10:03 AM, Greg Dove  wrote:
>
>>  Alex, I just issued a PR that lets you easily see the problem (along
>>with
>> a fix for ant script for the manual test).
>>
>> I had a quick look inside eventtarget.js and it seems pretty clear to
>>me:
>>
>> 
>>https://github.com/google/closure-library/blob/master/closure/goog/events
>>/
>> eventtarget.js#L349
>>
>> it is calling currentTarget.fireListeners and in the most basic case for
>> proxy event dispatching, this is the same as the 'targetForTesting'
>>which
>> requires that fireListeners is implemented on the alternate target.
>> when a subclass inherits EventDispatcher, currentTarget will always
>> be 'this' and so the same instance EventTarget's fireListeners method is
>> called directly.
>>
>> all the other variables and functions are referenced via 'this' which
>> would correctly resolve inside the proxy EventDispatcher instance,
>>although
>> they would all obviously be inherited if the class extends the flexjs
>> EventDispatcher.
>>
>> I guess we need something on goog's EventTarget that is more
>> setExternalTarget and that is only used for the event.target , not for
>>the
>> fireListeners call.
>>
>>
>>
>> On Thu, Sep 1, 2016 at 3:51 AM, Alex Harui  wrote:
>>
>>>
>>>
>>> On 8/31/16, 12:43 AM, "Greg Dove"  wrote:
>>>
>>> >I observed that issue when implementing  IEventdispatcher i.e. when
>>>the
>>> >EventDispatcher constructor has an IEventDispatcher argument - so not
>>>for
>>> >statics. This is not seen when extending EventDispatcher, but in that
>>> case
>>> >the subclass would presumably inherit that method from goog
>>>EventTarget.
>>> >So
>>> >that setCurrentTarget method in the constructor did not seem to be the
>>> >complete answer here... that extra hack in the constructor just got
>>> things
>>> >working for nowit works as is but I don't like it.
>>>
>>> Interesting.  Do you have a simple test case we can look at?  Looking
>>>at
>>> the EventTarget code, I would think there would be other functions and
>>> variables that need propagation.
>>>
>>> Thanks,
>>> -Alex
>>>
>>>
>>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

"I guess we need something on goog's EventTarget that is more
setExternalTarget and that is only used for the event.target , not for the
fireListeners call. "

This type of change to their eventtarget.js works [1] and all that is
needed is a change to setTargetForTesting(target) to be
setTargetForTesting(target,true) in our constructor. Then that hack I added
is no longer needed.

I have not issued any request against closure lib there yet, but can do so
if you think it is best (I don't know how it will be received). I'm not
entirely comfortable doing this on behalf of Apache Flex, so would prefer
if someone on the team did it.

I can't see another simpler way around this (which doesn't mean there isn't
one!). I definitely didn't want to put that method in the interface because
it would deviate from flash.



1.
https://github.com/greg-dove/closure-library/commit/6be3161f02cf327a0dc1a33f085f0531d2993b4e



On Thu, Sep 1, 2016 at 10:03 AM, Greg Dove  wrote:

>  Alex, I just issued a PR that lets you easily see the problem (along with
> a fix for ant script for the manual test).
>
> I had a quick look inside eventtarget.js and it seems pretty clear to me:
>
> https://github.com/google/closure-library/blob/master/closure/goog/events/
> eventtarget.js#L349
>
> it is calling currentTarget.fireListeners and in the most basic case for
> proxy event dispatching, this is the same as the 'targetForTesting' which
> requires that fireListeners is implemented on the alternate target.
> when a subclass inherits EventDispatcher, currentTarget will always
> be 'this' and so the same instance EventTarget's fireListeners method is
> called directly.
>
> all the other variables and functions are referenced via 'this' which
> would correctly resolve inside the proxy EventDispatcher instance, although
> they would all obviously be inherited if the class extends the flexjs
> EventDispatcher.
>
> I guess we need something on goog's EventTarget that is more
> setExternalTarget and that is only used for the event.target , not for the
> fireListeners call.
>
>
>
> On Thu, Sep 1, 2016 at 3:51 AM, Alex Harui  wrote:
>
>>
>>
>> On 8/31/16, 12:43 AM, "Greg Dove"  wrote:
>>
>> >I observed that issue when implementing  IEventdispatcher i.e. when the
>> >EventDispatcher constructor has an IEventDispatcher argument - so not for
>> >statics. This is not seen when extending EventDispatcher, but in that
>> case
>> >the subclass would presumably inherit that method from goog EventTarget.
>> >So
>> >that setCurrentTarget method in the constructor did not seem to be the
>> >complete answer here... that extra hack in the constructor just got
>> things
>> >working for nowit works as is but I don't like it.
>>
>> Interesting.  Do you have a simple test case we can look at?  Looking at
>> the EventTarget code, I would think there would be other functions and
>> variables that need propagation.
>>
>> Thanks,
>> -Alex
>>
>>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

 Alex, I just issued a PR that lets you easily see the problem (along with
a fix for ant script for the manual test).

I had a quick look inside eventtarget.js and it seems pretty clear to me:

https://github.com/google/closure-library/blob/master/closure/goog/events/eventtarget.js#L349

it is calling currentTarget.fireListeners and in the most basic case for
proxy event dispatching, this is the same as the 'targetForTesting' which
requires that fireListeners is implemented on the alternate target.
when a subclass inherits EventDispatcher, currentTarget will always
be 'this' and so the same instance EventTarget's fireListeners method is
called directly.

all the other variables and functions are referenced via 'this' which would
correctly resolve inside the proxy EventDispatcher instance, although they
would all obviously be inherited if the class extends the flexjs
EventDispatcher.

I guess we need something on goog's EventTarget that is more
setExternalTarget and that is only used for the event.target , not for the
fireListeners call.



On Thu, Sep 1, 2016 at 3:51 AM, Alex Harui  wrote:

>
>
> On 8/31/16, 12:43 AM, "Greg Dove"  wrote:
>
> >I observed that issue when implementing  IEventdispatcher i.e. when the
> >EventDispatcher constructor has an IEventDispatcher argument - so not for
> >statics. This is not seen when extending EventDispatcher, but in that case
> >the subclass would presumably inherit that method from goog EventTarget.
> >So
> >that setCurrentTarget method in the constructor did not seem to be the
> >complete answer here... that extra hack in the constructor just got things
> >working for nowit works as is but I don't like it.
>
> Interesting.  Do you have a simple test case we can look at?  Looking at
> the EventTarget code, I would think there would be other functions and
> variables that need propagation.
>
> Thanks,
> -Alex
>
>

Re: AW: AW: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

Chris,

I just looked through this code.  It appears that there are several
compiler options that are not listed in these files.  Should they all be
there?  Most of the missing ones are defaults set in flex-config.xml.  Of
the three Greg mentioned below only one isn't currently in flex-config.xml
and I would recommend just adding it there.  Then I think the java files
wouldn't "have to" change unless you want this code to support all
configuration options.

Thoughts?
-Alex

On 8/31/16, 1:32 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:

>Hi Greg,
>
>
>Well in the flexjs-maven-plugin the class BaseMojo and all classes
>derived from that for example define a whole bunch of properties like
>this (In CompileAppMojo):
>
>@Parameter(defaultValue = "false")
>protected boolean removeCirculars;
>
>So it defines a boolean config option "removeCirculars" which can be used
>in the pom.xml, or if missing, it uses a default of "false". In order to
>get the property into the compiler configuration file, for example you
>would need to add the property in the nearest mojo class, and make sure
>that property is added to the Velocity context:
>
>@Override
>protected VelocityContext getVelocityContext() throws
>MojoExecutionException {
>VelocityContext context = super.getVelocityContext();
>context.put("removeCirculars", removeCirculars);
>return context;
>}
>
>This makes it possible to access the property in the Velocity template I
>use to generate the compiler config file
>(compile-app-javascript-config.xml):
>
>
>$removeCirculars
>
>But you could just tell me which config option you deed in which
>compilation and I could add the option. I just thought documenting this
>use-case would be a good thing to do ;-)
>
>
>If you also tell me which examples need the option, we could then adjust
>the pom.xml for those projects.
>
>
>Chris
>
>
>
>
>
>
>Von: Greg Dove <greg.d...@gmail.com>
>Gesendet: Mittwoch, 31. August 2016 09:50:08
>An: dev@flex.apache.org
>Betreff: Re: AW: [FlexJX][Falcon] Binding support fixes/improvements
>
>Chris I will try to figure out tomorrow  how to do this type of thing for
>maven also. I don't recall seeing the other compiler config settings in
>pom.xml files when I looked for them so I must have been looking in the
>wrong place.
>
>-Greg
>[sent from my phone]
>
>On 31/08/2016 6:26 PM, "Christofer Dutz" <christofer.d...@c-ware.de>
>wrote:
>
>> What changes are needed fire the examples. Please keep in mind that they
>> also have to be applied to the Maven build to prevent it from diverging
>> from the ant one.
>>
>> Chris
>>
>>
>>
>> Von meinem Samsung Galaxy Smartphone gesendet.
>>
>>
>>  Ursprüngliche Nachricht 
>> Von: Greg Dove <greg.d...@gmail.com>
>> Datum: 30.08.16 22:12 (GMT+01:00)
>> An: dev@flex.apache.org
>> Betreff: Re: [FlexJX][Falcon] Binding support fixes/improvements
>>
>> Thanks for the feedback Alex.
>> I had also received encouragement from Justin a long time ago to
>> contribute, I'm happy that I finally got a chance to do so.
>>
>> tbh I had not even looked inside manual tests folder yet (there's a lot
>>in
>> there!), but that definitely sounds like a better place for that
>>example,
>> it really is a 'manual test'.
>>
>> it might require the addition of :
>>
>> > value="-compiler.binding-event-handler-interface=org.apache.flex.events.
>> IEventDispatcher"
>> />
>> > value="-compiler.binding-event-handler-class=org.apache.flex.events.
>> EventDispatcher"
>> />
>> > 
>>value="-compiler.binding-event-handler-event=org.apache.flex.events.Event
>>"
>> />
>>
>> to the build_example ant file targets, if you didn't already add it
>>
>> In terms of my sleeves, I hope to find something more up there within
>>the
>> next couple of weeks. My regular client work is in a bit of a lull, so
>>I am
>> making use of the time to get familiar with FlexJS.
>> I actually already started work on updates in reflection, and only
>>ended up
>> in bindings because I saw some issues. I will go back to reflection
>>again
>> next, with a goal of getting identical results in swf and js. Some of
>>the
>> stuff I added to the JSSessionModel will help with what I needed to do
>> there anyhow.
>>
>> I will definitely add to or update any relevant existing unit-tests on
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 8/31/16, 12:43 AM, "Greg Dove"  wrote:

>I observed that issue when implementing  IEventdispatcher i.e. when the
>EventDispatcher constructor has an IEventDispatcher argument - so not for
>statics. This is not seen when extending EventDispatcher, but in that case
>the subclass would presumably inherit that method from goog EventTarget.
>So
>that setCurrentTarget method in the constructor did not seem to be the
>complete answer here... that extra hack in the constructor just got things
>working for nowit works as is but I don't like it.

Interesting.  Do you have a simple test case we can look at?  Looking at
the EventTarget code, I would think there would be other functions and
variables that need propagation.

Thanks,
-Alex

AW: AW: [FlexJX][Falcon] Binding support fixes/improvements

[Christofer Dutz]

Hi Greg,


Well in the flexjs-maven-plugin the class BaseMojo and all classes derived from 
that for example define a whole bunch of properties like this (In 
CompileAppMojo):

@Parameter(defaultValue = "false")
protected boolean removeCirculars;

So it defines a boolean config option "removeCirculars" which can be used in 
the pom.xml, or if missing, it uses a default of "false". In order to get the 
property into the compiler configuration file, for example you would need to 
add the property in the nearest mojo class, and make sure that property is 
added to the Velocity context:

@Override
protected VelocityContext getVelocityContext() throws MojoExecutionException {
VelocityContext context = super.getVelocityContext();
context.put("removeCirculars", removeCirculars);
return context;
}

This makes it possible to access the property in the Velocity template I use to 
generate the compiler config file (compile-app-javascript-config.xml):


$removeCirculars

But you could just tell me which config option you deed in which compilation 
and I could add the option. I just thought documenting this use-case would be a 
good thing to do ;-)


If you also tell me which examples need the option, we could then adjust the 
pom.xml for those projects.


Chris






Von: Greg Dove <greg.d...@gmail.com>
Gesendet: Mittwoch, 31. August 2016 09:50:08
An: dev@flex.apache.org
Betreff: Re: AW: [FlexJX][Falcon] Binding support fixes/improvements

Chris I will try to figure out tomorrow  how to do this type of thing for
maven also. I don't recall seeing the other compiler config settings in
pom.xml files when I looked for them so I must have been looking in the
wrong place.

-Greg
[sent from my phone]

On 31/08/2016 6:26 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:

> What changes are needed fire the examples. Please keep in mind that they
> also have to be applied to the Maven build to prevent it from diverging
> from the ant one.
>
> Chris
>
>
>
> Von meinem Samsung Galaxy Smartphone gesendet.
>
>
>  Ursprüngliche Nachricht 
> Von: Greg Dove <greg.d...@gmail.com>
> Datum: 30.08.16 22:12 (GMT+01:00)
> An: dev@flex.apache.org
> Betreff: Re: [FlexJX][Falcon] Binding support fixes/improvements
>
> Thanks for the feedback Alex.
> I had also received encouragement from Justin a long time ago to
> contribute, I'm happy that I finally got a chance to do so.
>
> tbh I had not even looked inside manual tests folder yet (there's a lot in
> there!), but that definitely sounds like a better place for that example,
> it really is a 'manual test'.
>
> it might require the addition of :
>
>  value="-compiler.binding-event-handler-interface=org.apache.flex.events.
> IEventDispatcher"
> />
>  value="-compiler.binding-event-handler-class=org.apache.flex.events.
> EventDispatcher"
> />
>  value="-compiler.binding-event-handler-event=org.apache.flex.events.Event"
> />
>
> to the build_example ant file targets, if you didn't already add it
>
> In terms of my sleeves, I hope to find something more up there within the
> next couple of weeks. My regular client work is in a bit of a lull, so I am
> making use of the time to get familiar with FlexJS.
> I actually already started work on updates in reflection, and only ended up
> in bindings because I saw some issues. I will go back to reflection again
> next, with a goal of getting identical results in swf and js. Some of the
> stuff I added to the JSSessionModel will help with what I needed to do
> there anyhow.
>
> I will definitely add to or update any relevant existing unit-tests on this
> next work.
>
> cheers,
> Greg
>
>
>
> On Tue, Aug 30, 2016 at 7:34 PM, Alex Harui <aha...@adobe.com> wrote:
>
> > Hi Greg,
> >
> > OK, I looked through your patches and applied them to the develop branch.
> > I couldn't see anything obviously wrong with it, so great job and thanks
> > for contributing!  I hope you have more up your sleeve.
> >
> > FWIW, it would be nice to unit tests in flex-falcon and maybe flex-asjs.
> > I'm going to move your example to the manual tests folder in a minute
> here
> > as I think it belongs there.
> >
> > Thanks again,
> > -Alex
> >
> > On 8/28/16, 10:10 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
> >
> > >Hey Alex, sorry I wasn't clear.
> > >
> > >"Without a test case to step through the code, I have to say that it is
> a
> > >bit surprising that you fixed the jx output by fiddling with
> > >ASCompilationUnit and ClassDirectiveProcessor instead of the emitters.&qu

Re: AW: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Chris I will try to figure out tomorrow  how to do this type of thing for
maven also. I don't recall seeing the other compiler config settings in
pom.xml files when I looked for them so I must have been looking in the
wrong place.

-Greg
[sent from my phone]

On 31/08/2016 6:26 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:

> What changes are needed fire the examples. Please keep in mind that they
> also have to be applied to the Maven build to prevent it from diverging
> from the ant one.
>
> Chris
>
>
>
> Von meinem Samsung Galaxy Smartphone gesendet.
>
>
>  Ursprüngliche Nachricht 
> Von: Greg Dove <greg.d...@gmail.com>
> Datum: 30.08.16 22:12 (GMT+01:00)
> An: dev@flex.apache.org
> Betreff: Re: [FlexJX][Falcon] Binding support fixes/improvements
>
> Thanks for the feedback Alex.
> I had also received encouragement from Justin a long time ago to
> contribute, I'm happy that I finally got a chance to do so.
>
> tbh I had not even looked inside manual tests folder yet (there's a lot in
> there!), but that definitely sounds like a better place for that example,
> it really is a 'manual test'.
>
> it might require the addition of :
>
>  value="-compiler.binding-event-handler-interface=org.apache.flex.events.
> IEventDispatcher"
> />
>  value="-compiler.binding-event-handler-class=org.apache.flex.events.
> EventDispatcher"
> />
>  value="-compiler.binding-event-handler-event=org.apache.flex.events.Event"
> />
>
> to the build_example ant file targets, if you didn't already add it
>
> In terms of my sleeves, I hope to find something more up there within the
> next couple of weeks. My regular client work is in a bit of a lull, so I am
> making use of the time to get familiar with FlexJS.
> I actually already started work on updates in reflection, and only ended up
> in bindings because I saw some issues. I will go back to reflection again
> next, with a goal of getting identical results in swf and js. Some of the
> stuff I added to the JSSessionModel will help with what I needed to do
> there anyhow.
>
> I will definitely add to or update any relevant existing unit-tests on this
> next work.
>
> cheers,
> Greg
>
>
>
> On Tue, Aug 30, 2016 at 7:34 PM, Alex Harui <aha...@adobe.com> wrote:
>
> > Hi Greg,
> >
> > OK, I looked through your patches and applied them to the develop branch.
> > I couldn't see anything obviously wrong with it, so great job and thanks
> > for contributing!  I hope you have more up your sleeve.
> >
> > FWIW, it would be nice to unit tests in flex-falcon and maybe flex-asjs.
> > I'm going to move your example to the manual tests folder in a minute
> here
> > as I think it belongs there.
> >
> > Thanks again,
> > -Alex
> >
> > On 8/28/16, 10:10 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
> >
> > >Hey Alex, sorry I wasn't clear.
> > >
> > >"Without a test case to step through the code, I have to say that it is
> a
> > >bit surprising that you fixed the jx output by fiddling with
> > >ASCompilationUnit and ClassDirectiveProcessor instead of the emitters."
> > >
> > >I meant specifically emitters outside of jx js emitters, and VF2JS was
> an
> > >example of one I did not touch. AMD is another. I definitely made
> changes
> > >in the FlexJSEmitter stuff.
> > >
> > >The ClassDIrectiveProcessor change was just for falcon/swf - I made
> > >similar
> > >changes for the js emitters, and implemented the IEventDispatcher
> > >variation
> > >as well as it was not currently implemented in jx.
> > >
> > >I will be submitting PRs within the next 15 mins. I won't add a lot of
> > >text
> > >with the PR - so please ask if you have any questions as to why I did
> > >things the way I did. Some of it may be a little 'clumsy' perhaps.
> > >
> > >cheers
> > >Greg
> > >
> > >On Mon, Aug 29, 2016 at 5:04 PM, Alex Harui <aha...@adobe.com> wrote:
> > >
> > >> Hi Greg,
> > >>
> > >> Without a test case to step through the code, I have to say that it
> is a
> > >> bit surprising that you fixed the jx output by fiddling with
> > >> ASCompilationUnit and ClassDirectiveProcessor instead of the emitters.
> > >>
> > >> I guess I'll wait to see the PR.  Maybe it will make more sense
> then.  I
> > >> guess maybe you needed to make that change to affect the AST?
> > >>
> > >

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

I observed that issue when implementing  IEventdispatcher i.e. when the
EventDispatcher constructor has an IEventDispatcher argument - so not for
statics. This is not seen when extending EventDispatcher, but in that case
the subclass would presumably inherit that method from goog EventTarget. So
that setCurrentTarget method in the constructor did not seem to be the
complete answer here... that extra hack in the constructor just got things
working for nowit works as is but I don't like it.

-Greg
[sent from my phone]

On 31/08/2016 6:59 PM, "Alex Harui"  wrote:

>
>
> On 8/30/16, 1:41 PM, "Greg Dove"  wrote:
>
> >Before I forget, I have 2 extra questions :
> >
> >1. I wasn't real happy with the change I made for js in
> >org.apache.flex.events.EventDispatcher. At the time it was the easiest
> >solution. I did not look too deep into the goog base class to see if there
> >was a more official way to avoid this. I will take the time to do that in
> >the coming days. But if there is not an 'official' way, is the best
> >solution to maybe lodge an issue with them (if so, I can, just wanted to
> >check first, in case we apply patches or something like that).
>
> Can you explain when this code is needed?  Is this for the static event
> dispatcher?  Or for a custom IEventDispatcher?
>
> Thanks,
> -Alex
>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

On 8/30/16, 1:41 PM, "Greg Dove"  wrote:

>Before I forget, I have 2 extra questions :
>
>1. I wasn't real happy with the change I made for js in
>org.apache.flex.events.EventDispatcher. At the time it was the easiest
>solution. I did not look too deep into the goog base class to see if there
>was a more official way to avoid this. I will take the time to do that in
>the coming days. But if there is not an 'official' way, is the best
>solution to maybe lodge an issue with them (if so, I can, just wanted to
>check first, in case we apply patches or something like that).

Can you explain when this code is needed?  Is this for the static event
dispatcher?  Or for a custom IEventDispatcher?

Thanks,
-Alex

AW: [FlexJX][Falcon] Binding support fixes/improvements

[Christofer Dutz]

What changes are needed fire the examples. Please keep in mind that they also 
have to be applied to the Maven build to prevent it from diverging from the ant 
one.

Chris



Von meinem Samsung Galaxy Smartphone gesendet.


 Ursprüngliche Nachricht 
Von: Greg Dove <greg.d...@gmail.com>
Datum: 30.08.16 22:12 (GMT+01:00)
An: dev@flex.apache.org
Betreff: Re: [FlexJX][Falcon] Binding support fixes/improvements

Thanks for the feedback Alex.
I had also received encouragement from Justin a long time ago to
contribute, I'm happy that I finally got a chance to do so.

tbh I had not even looked inside manual tests folder yet (there's a lot in
there!), but that definitely sounds like a better place for that example,
it really is a 'manual test'.

it might require the addition of :





to the build_example ant file targets, if you didn't already add it

In terms of my sleeves, I hope to find something more up there within the
next couple of weeks. My regular client work is in a bit of a lull, so I am
making use of the time to get familiar with FlexJS.
I actually already started work on updates in reflection, and only ended up
in bindings because I saw some issues. I will go back to reflection again
next, with a goal of getting identical results in swf and js. Some of the
stuff I added to the JSSessionModel will help with what I needed to do
there anyhow.

I will definitely add to or update any relevant existing unit-tests on this
next work.

cheers,
Greg



On Tue, Aug 30, 2016 at 7:34 PM, Alex Harui <aha...@adobe.com> wrote:

> Hi Greg,
>
> OK, I looked through your patches and applied them to the develop branch.
> I couldn't see anything obviously wrong with it, so great job and thanks
> for contributing!  I hope you have more up your sleeve.
>
> FWIW, it would be nice to unit tests in flex-falcon and maybe flex-asjs.
> I'm going to move your example to the manual tests folder in a minute here
> as I think it belongs there.
>
> Thanks again,
> -Alex
>
> On 8/28/16, 10:10 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> >Hey Alex, sorry I wasn't clear.
> >
> >"Without a test case to step through the code, I have to say that it is a
> >bit surprising that you fixed the jx output by fiddling with
> >ASCompilationUnit and ClassDirectiveProcessor instead of the emitters."
> >
> >I meant specifically emitters outside of jx js emitters, and VF2JS was an
> >example of one I did not touch. AMD is another. I definitely made changes
> >in the FlexJSEmitter stuff.
> >
> >The ClassDIrectiveProcessor change was just for falcon/swf - I made
> >similar
> >changes for the js emitters, and implemented the IEventDispatcher
> >variation
> >as well as it was not currently implemented in jx.
> >
> >I will be submitting PRs within the next 15 mins. I won't add a lot of
> >text
> >with the PR - so please ask if you have any questions as to why I did
> >things the way I did. Some of it may be a little 'clumsy' perhaps.
> >
> >cheers
> >Greg
> >
> >On Mon, Aug 29, 2016 at 5:04 PM, Alex Harui <aha...@adobe.com> wrote:
> >
> >> Hi Greg,
> >>
> >> Without a test case to step through the code, I have to say that it is a
> >> bit surprising that you fixed the jx output by fiddling with
> >> ASCompilationUnit and ClassDirectiveProcessor instead of the emitters.
> >>
> >> I guess I'll wait to see the PR.  Maybe it will make more sense then.  I
> >> guess maybe you needed to make that change to affect the AST?
> >>
> >> Fundamentally, the compiler creates an AST, then Falcon (the SWF
> >>compiler)
> >> uses Reducers to reduce the AST to ABC code.  FalconJX uses BlockWalkers
> >> and Emitters.  There are different emitters for different output
> >>formats.
> >> The vf2js emitters were an attempt to do a straight cross-compile of the
> >> existing Flex SDK code.  It is not being used by FlexJS.
> >>
> >> Looking forward to it,
> >> -Alex
> >>
> >> On 8/28/16, 8:51 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
> >>
> >> >Thanks Alex,
> >> >
> >> >There are definitely bugs, and I have addressed those that I found in
> >>the
> >> >testbed example I already made a PR for. The others should beWhether I
> >> >have
> >> >addressed them appropriately or not I can't say, but if the way I have
> >> >done
> >> >things is not consistent with the compiler architecture or any general
> >> >java
> >> >coding standards, then at the very least it should provide clues for

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Please ignore: " Is there a public bugbase or tasklist anywhere for the
project ?"

Justin pointed me to the jira issues. I will likely address a couple of
these when I work on the reflection stuff, and will be happy to work
through some of the others later on, if they are still current issues.

cheers,
Greg


On Wed, Aug 31, 2016 at 8:41 AM, Greg Dove  wrote:

> Before I forget, I have 2 extra questions :
>
> 1. I wasn't real happy with the change I made for js in
> org.apache.flex.events.EventDispatcher. At the time it was the easiest
> solution. I did not look too deep into the goog base class to see if there
> was a more official way to avoid this. I will take the time to do that in
> the coming days. But if there is not an 'official' way, is the best
> solution to maybe lodge an issue with them (if so, I can, just wanted to
> check first, in case we apply patches or something like that).
>
> 2. Is there a public bugbase or tasklist anywhere for the project ? I'm
> doing self-directed stuff now, but open to helping out generally in the
> future (time permitting).
>
>
>
> On Wed, Aug 31, 2016 at 8:12 AM, Greg Dove  wrote:
>
>> Thanks for the feedback Alex.
>> I had also received encouragement from Justin a long time ago to
>> contribute, I'm happy that I finally got a chance to do so.
>>
>> tbh I had not even looked inside manual tests folder yet (there's a lot
>> in there!), but that definitely sounds like a better place for that
>> example, it really is a 'manual test'.
>>
>> it might require the addition of :
>>
>> > value="-compiler.binding-event-handler-interface=org.apache.flex.events.IEventDispatcher"
>> />
>> > value="-compiler.binding-event-handler-class=org.apache.flex.events.EventDispatcher"
>> />
>> > value="-compiler.binding-event-handler-event=org.apache.flex.events.Event"
>> />
>>
>> to the build_example ant file targets, if you didn't already add it
>>
>> In terms of my sleeves, I hope to find something more up there within the
>> next couple of weeks. My regular client work is in a bit of a lull, so I am
>> making use of the time to get familiar with FlexJS.
>> I actually already started work on updates in reflection, and only ended
>> up in bindings because I saw some issues. I will go back to reflection
>> again next, with a goal of getting identical results in swf and js. Some of
>> the stuff I added to the JSSessionModel will help with what I needed to do
>> there anyhow.
>>
>> I will definitely add to or update any relevant existing unit-tests on
>> this next work.
>>
>> cheers,
>> Greg
>>
>>
>>
>> On Tue, Aug 30, 2016 at 7:34 PM, Alex Harui  wrote:
>>
>>> Hi Greg,
>>>
>>> OK, I looked through your patches and applied them to the develop branch.
>>> I couldn't see anything obviously wrong with it, so great job and thanks
>>> for contributing!  I hope you have more up your sleeve.
>>>
>>> FWIW, it would be nice to unit tests in flex-falcon and maybe flex-asjs.
>>> I'm going to move your example to the manual tests folder in a minute
>>> here
>>> as I think it belongs there.
>>>
>>> Thanks again,
>>> -Alex
>>>
>>> On 8/28/16, 10:10 PM, "Greg Dove"  wrote:
>>>
>>> >Hey Alex, sorry I wasn't clear.
>>> >
>>> >"Without a test case to step through the code, I have to say that it is
>>> a
>>> >bit surprising that you fixed the jx output by fiddling with
>>> >ASCompilationUnit and ClassDirectiveProcessor instead of the emitters."
>>> >
>>> >I meant specifically emitters outside of jx js emitters, and VF2JS was
>>> an
>>> >example of one I did not touch. AMD is another. I definitely made
>>> changes
>>> >in the FlexJSEmitter stuff.
>>> >
>>> >The ClassDIrectiveProcessor change was just for falcon/swf - I made
>>> >similar
>>> >changes for the js emitters, and implemented the IEventDispatcher
>>> >variation
>>> >as well as it was not currently implemented in jx.
>>> >
>>> >I will be submitting PRs within the next 15 mins. I won't add a lot of
>>> >text
>>> >with the PR - so please ask if you have any questions as to why I did
>>> >things the way I did. Some of it may be a little 'clumsy' perhaps.
>>> >
>>> >cheers
>>> >Greg
>>> >
>>> >On Mon, Aug 29, 2016 at 5:04 PM, Alex Harui  wrote:
>>> >
>>> >> Hi Greg,
>>> >>
>>> >> Without a test case to step through the code, I have to say that it
>>> is a
>>> >> bit surprising that you fixed the jx output by fiddling with
>>> >> ASCompilationUnit and ClassDirectiveProcessor instead of the emitters.
>>> >>
>>> >> I guess I'll wait to see the PR.  Maybe it will make more sense
>>> then.  I
>>> >> guess maybe you needed to make that change to affect the AST?
>>> >>
>>> >> Fundamentally, the compiler creates an AST, then Falcon (the SWF
>>> >>compiler)
>>> >> uses Reducers to reduce the AST to ABC code.  FalconJX uses
>>> BlockWalkers
>>> >> and Emitters.  There are different emitters for different output
>>> >>formats.
>>> >> The vf2js emitters were an 

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Before I forget, I have 2 extra questions :

1. I wasn't real happy with the change I made for js in
org.apache.flex.events.EventDispatcher. At the time it was the easiest
solution. I did not look too deep into the goog base class to see if there
was a more official way to avoid this. I will take the time to do that in
the coming days. But if there is not an 'official' way, is the best
solution to maybe lodge an issue with them (if so, I can, just wanted to
check first, in case we apply patches or something like that).

2. Is there a public bugbase or tasklist anywhere for the project ? I'm
doing self-directed stuff now, but open to helping out generally in the
future (time permitting).



On Wed, Aug 31, 2016 at 8:12 AM, Greg Dove  wrote:

> Thanks for the feedback Alex.
> I had also received encouragement from Justin a long time ago to
> contribute, I'm happy that I finally got a chance to do so.
>
> tbh I had not even looked inside manual tests folder yet (there's a lot in
> there!), but that definitely sounds like a better place for that example,
> it really is a 'manual test'.
>
> it might require the addition of :
>
> 
>  value="-compiler.binding-event-handler-class=org.apache.flex.events.EventDispatcher"
> />
>  value="-compiler.binding-event-handler-event=org.apache.flex.events.Event"
> />
>
> to the build_example ant file targets, if you didn't already add it
>
> In terms of my sleeves, I hope to find something more up there within the
> next couple of weeks. My regular client work is in a bit of a lull, so I am
> making use of the time to get familiar with FlexJS.
> I actually already started work on updates in reflection, and only ended
> up in bindings because I saw some issues. I will go back to reflection
> again next, with a goal of getting identical results in swf and js. Some of
> the stuff I added to the JSSessionModel will help with what I needed to do
> there anyhow.
>
> I will definitely add to or update any relevant existing unit-tests on
> this next work.
>
> cheers,
> Greg
>
>
>
> On Tue, Aug 30, 2016 at 7:34 PM, Alex Harui  wrote:
>
>> Hi Greg,
>>
>> OK, I looked through your patches and applied them to the develop branch.
>> I couldn't see anything obviously wrong with it, so great job and thanks
>> for contributing!  I hope you have more up your sleeve.
>>
>> FWIW, it would be nice to unit tests in flex-falcon and maybe flex-asjs.
>> I'm going to move your example to the manual tests folder in a minute here
>> as I think it belongs there.
>>
>> Thanks again,
>> -Alex
>>
>> On 8/28/16, 10:10 PM, "Greg Dove"  wrote:
>>
>> >Hey Alex, sorry I wasn't clear.
>> >
>> >"Without a test case to step through the code, I have to say that it is a
>> >bit surprising that you fixed the jx output by fiddling with
>> >ASCompilationUnit and ClassDirectiveProcessor instead of the emitters."
>> >
>> >I meant specifically emitters outside of jx js emitters, and VF2JS was an
>> >example of one I did not touch. AMD is another. I definitely made changes
>> >in the FlexJSEmitter stuff.
>> >
>> >The ClassDIrectiveProcessor change was just for falcon/swf - I made
>> >similar
>> >changes for the js emitters, and implemented the IEventDispatcher
>> >variation
>> >as well as it was not currently implemented in jx.
>> >
>> >I will be submitting PRs within the next 15 mins. I won't add a lot of
>> >text
>> >with the PR - so please ask if you have any questions as to why I did
>> >things the way I did. Some of it may be a little 'clumsy' perhaps.
>> >
>> >cheers
>> >Greg
>> >
>> >On Mon, Aug 29, 2016 at 5:04 PM, Alex Harui  wrote:
>> >
>> >> Hi Greg,
>> >>
>> >> Without a test case to step through the code, I have to say that it is
>> a
>> >> bit surprising that you fixed the jx output by fiddling with
>> >> ASCompilationUnit and ClassDirectiveProcessor instead of the emitters.
>> >>
>> >> I guess I'll wait to see the PR.  Maybe it will make more sense then.
>> I
>> >> guess maybe you needed to make that change to affect the AST?
>> >>
>> >> Fundamentally, the compiler creates an AST, then Falcon (the SWF
>> >>compiler)
>> >> uses Reducers to reduce the AST to ABC code.  FalconJX uses
>> BlockWalkers
>> >> and Emitters.  There are different emitters for different output
>> >>formats.
>> >> The vf2js emitters were an attempt to do a straight cross-compile of
>> the
>> >> existing Flex SDK code.  It is not being used by FlexJS.
>> >>
>> >> Looking forward to it,
>> >> -Alex
>> >>
>> >> On 8/28/16, 8:51 PM, "Greg Dove"  wrote:
>> >>
>> >> >Thanks Alex,
>> >> >
>> >> >There are definitely bugs, and I have addressed those that I found in
>> >>the
>> >> >testbed example I already made a PR for. The others should beWhether I
>> >> >have
>> >> >addressed them appropriately or not I can't say, but if the way I have
>> >> >done
>> >> >things is not consistent with the compiler architecture or any general
>> >> >java
>> >> 

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Thanks for the feedback Alex.
I had also received encouragement from Justin a long time ago to
contribute, I'm happy that I finally got a chance to do so.

tbh I had not even looked inside manual tests folder yet (there's a lot in
there!), but that definitely sounds like a better place for that example,
it really is a 'manual test'.

it might require the addition of :





to the build_example ant file targets, if you didn't already add it

In terms of my sleeves, I hope to find something more up there within the
next couple of weeks. My regular client work is in a bit of a lull, so I am
making use of the time to get familiar with FlexJS.
I actually already started work on updates in reflection, and only ended up
in bindings because I saw some issues. I will go back to reflection again
next, with a goal of getting identical results in swf and js. Some of the
stuff I added to the JSSessionModel will help with what I needed to do
there anyhow.

I will definitely add to or update any relevant existing unit-tests on this
next work.

cheers,
Greg



On Tue, Aug 30, 2016 at 7:34 PM, Alex Harui  wrote:

> Hi Greg,
>
> OK, I looked through your patches and applied them to the develop branch.
> I couldn't see anything obviously wrong with it, so great job and thanks
> for contributing!  I hope you have more up your sleeve.
>
> FWIW, it would be nice to unit tests in flex-falcon and maybe flex-asjs.
> I'm going to move your example to the manual tests folder in a minute here
> as I think it belongs there.
>
> Thanks again,
> -Alex
>
> On 8/28/16, 10:10 PM, "Greg Dove"  wrote:
>
> >Hey Alex, sorry I wasn't clear.
> >
> >"Without a test case to step through the code, I have to say that it is a
> >bit surprising that you fixed the jx output by fiddling with
> >ASCompilationUnit and ClassDirectiveProcessor instead of the emitters."
> >
> >I meant specifically emitters outside of jx js emitters, and VF2JS was an
> >example of one I did not touch. AMD is another. I definitely made changes
> >in the FlexJSEmitter stuff.
> >
> >The ClassDIrectiveProcessor change was just for falcon/swf - I made
> >similar
> >changes for the js emitters, and implemented the IEventDispatcher
> >variation
> >as well as it was not currently implemented in jx.
> >
> >I will be submitting PRs within the next 15 mins. I won't add a lot of
> >text
> >with the PR - so please ask if you have any questions as to why I did
> >things the way I did. Some of it may be a little 'clumsy' perhaps.
> >
> >cheers
> >Greg
> >
> >On Mon, Aug 29, 2016 at 5:04 PM, Alex Harui  wrote:
> >
> >> Hi Greg,
> >>
> >> Without a test case to step through the code, I have to say that it is a
> >> bit surprising that you fixed the jx output by fiddling with
> >> ASCompilationUnit and ClassDirectiveProcessor instead of the emitters.
> >>
> >> I guess I'll wait to see the PR.  Maybe it will make more sense then.  I
> >> guess maybe you needed to make that change to affect the AST?
> >>
> >> Fundamentally, the compiler creates an AST, then Falcon (the SWF
> >>compiler)
> >> uses Reducers to reduce the AST to ABC code.  FalconJX uses BlockWalkers
> >> and Emitters.  There are different emitters for different output
> >>formats.
> >> The vf2js emitters were an attempt to do a straight cross-compile of the
> >> existing Flex SDK code.  It is not being used by FlexJS.
> >>
> >> Looking forward to it,
> >> -Alex
> >>
> >> On 8/28/16, 8:51 PM, "Greg Dove"  wrote:
> >>
> >> >Thanks Alex,
> >> >
> >> >There are definitely bugs, and I have addressed those that I found in
> >>the
> >> >testbed example I already made a PR for. The others should beWhether I
> >> >have
> >> >addressed them appropriately or not I can't say, but if the way I have
> >> >done
> >> >things is not consistent with the compiler architecture or any general
> >> >java
> >> >coding standards, then at the very least it should provide clues for
> >>you
> >> >or
> >> >someone else for what needs to be done in a more appropriate way. And
> >>if
> >> >it
> >> >is unclear why I did anything in particular please ask.
> >> >
> >> >One of the things I ended up doing was to move the 'extends
> >> >EventDispatcher' implementation from ASCompilationUnit to
> >> >ClassDIrectiveProcessor for falcon and to provide a corresponding
> >> >implementation in jx. There seemed to be times when that original
> >> >implementation was not being applied when it ought to have been, and it
> >> >also seemed like ClassDirectiveProcessor was a more natural home for
> >>it,
> >> >alongside the other 'implements IEventDispatcher' implementation for
> >> >binding support.
> >> >
> >> >
> >> >In terms of your suggestion about asking questions... I appreciate your
> >> >intent here, I think most people prefer not to ask stupid questions
> >>(even
> >> >if there is a culture of 'no such thing as a stupid question'), and I
> >> >needed to get my head around the compiler a bit 

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

Hi Greg,

OK, I looked through your patches and applied them to the develop branch.
I couldn't see anything obviously wrong with it, so great job and thanks
for contributing!  I hope you have more up your sleeve.

FWIW, it would be nice to unit tests in flex-falcon and maybe flex-asjs.
I'm going to move your example to the manual tests folder in a minute here
as I think it belongs there.

Thanks again,
-Alex

On 8/28/16, 10:10 PM, "Greg Dove"  wrote:

>Hey Alex, sorry I wasn't clear.
>
>"Without a test case to step through the code, I have to say that it is a
>bit surprising that you fixed the jx output by fiddling with
>ASCompilationUnit and ClassDirectiveProcessor instead of the emitters."
>
>I meant specifically emitters outside of jx js emitters, and VF2JS was an
>example of one I did not touch. AMD is another. I definitely made changes
>in the FlexJSEmitter stuff.
>
>The ClassDIrectiveProcessor change was just for falcon/swf - I made
>similar
>changes for the js emitters, and implemented the IEventDispatcher
>variation
>as well as it was not currently implemented in jx.
>
>I will be submitting PRs within the next 15 mins. I won't add a lot of
>text
>with the PR - so please ask if you have any questions as to why I did
>things the way I did. Some of it may be a little 'clumsy' perhaps.
>
>cheers
>Greg
>
>On Mon, Aug 29, 2016 at 5:04 PM, Alex Harui  wrote:
>
>> Hi Greg,
>>
>> Without a test case to step through the code, I have to say that it is a
>> bit surprising that you fixed the jx output by fiddling with
>> ASCompilationUnit and ClassDirectiveProcessor instead of the emitters.
>>
>> I guess I'll wait to see the PR.  Maybe it will make more sense then.  I
>> guess maybe you needed to make that change to affect the AST?
>>
>> Fundamentally, the compiler creates an AST, then Falcon (the SWF
>>compiler)
>> uses Reducers to reduce the AST to ABC code.  FalconJX uses BlockWalkers
>> and Emitters.  There are different emitters for different output
>>formats.
>> The vf2js emitters were an attempt to do a straight cross-compile of the
>> existing Flex SDK code.  It is not being used by FlexJS.
>>
>> Looking forward to it,
>> -Alex
>>
>> On 8/28/16, 8:51 PM, "Greg Dove"  wrote:
>>
>> >Thanks Alex,
>> >
>> >There are definitely bugs, and I have addressed those that I found in
>>the
>> >testbed example I already made a PR for. The others should beWhether I
>> >have
>> >addressed them appropriately or not I can't say, but if the way I have
>> >done
>> >things is not consistent with the compiler architecture or any general
>> >java
>> >coding standards, then at the very least it should provide clues for
>>you
>> >or
>> >someone else for what needs to be done in a more appropriate way. And
>>if
>> >it
>> >is unclear why I did anything in particular please ask.
>> >
>> >One of the things I ended up doing was to move the 'extends
>> >EventDispatcher' implementation from ASCompilationUnit to
>> >ClassDIrectiveProcessor for falcon and to provide a corresponding
>> >implementation in jx. There seemed to be times when that original
>> >implementation was not being applied when it ought to have been, and it
>> >also seemed like ClassDirectiveProcessor was a more natural home for
>>it,
>> >alongside the other 'implements IEventDispatcher' implementation for
>> >binding support.
>> >
>> >
>> >In terms of your suggestion about asking questions... I appreciate your
>> >intent here, I think most people prefer not to ask stupid questions
>>(even
>> >if there is a culture of 'no such thing as a stupid question'), and I
>> >needed to get my head around the compiler a bit first before asking too
>> >many questions, otherwise most of the questions would probably be
>>stupid
>> >ones about how it works!
>> >I used this exercise to help me understand the basics, and I personally
>> >find this approach is much better for for me to learn anything new over
>> >asking lots of questions (it may not be the most efficient to arrive at
>> >the
>> >knowledge, but it helps me get to a deeper understanding faster I
>>think).
>> >Also, although all you guys are great at responding quickly here, I am
>> >used
>> >to the immediacy of some form of chat, otherwise I am usually already
>> >trying to answer my questions myself, particularly if I am already
>>focused
>> >on it.  IRC is a good option here that some OS teams use, because it is
>> >possible to set up some logging (and therefore can be made searchable,
>>if
>> >required). But some people find IRC a bit 'old school' :).
>> >
>> >I will likely ask more questions in the future, but I do have a more
>> >general question now:
>> >
>> >Also, in terms of changing emitter support in jx for js output, I have
>>not
>> >touched anything outside of js emitters - is that usually ok? I don't
>>even
>> >know what vf2js or some of the others are for but I do see that
>>some
>> >of
>> >the various emitter classes have duplicated or similar 

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Hey Alex, sorry I wasn't clear.

"Without a test case to step through the code, I have to say that it is a
bit surprising that you fixed the jx output by fiddling with
ASCompilationUnit and ClassDirectiveProcessor instead of the emitters."

I meant specifically emitters outside of jx js emitters, and VF2JS was an
example of one I did not touch. AMD is another. I definitely made changes
in the FlexJSEmitter stuff.

The ClassDIrectiveProcessor change was just for falcon/swf - I made similar
changes for the js emitters, and implemented the IEventDispatcher variation
as well as it was not currently implemented in jx.

I will be submitting PRs within the next 15 mins. I won't add a lot of text
with the PR - so please ask if you have any questions as to why I did
things the way I did. Some of it may be a little 'clumsy' perhaps.

cheers
Greg

On Mon, Aug 29, 2016 at 5:04 PM, Alex Harui  wrote:

> Hi Greg,
>
> Without a test case to step through the code, I have to say that it is a
> bit surprising that you fixed the jx output by fiddling with
> ASCompilationUnit and ClassDirectiveProcessor instead of the emitters.
>
> I guess I'll wait to see the PR.  Maybe it will make more sense then.  I
> guess maybe you needed to make that change to affect the AST?
>
> Fundamentally, the compiler creates an AST, then Falcon (the SWF compiler)
> uses Reducers to reduce the AST to ABC code.  FalconJX uses BlockWalkers
> and Emitters.  There are different emitters for different output formats.
> The vf2js emitters were an attempt to do a straight cross-compile of the
> existing Flex SDK code.  It is not being used by FlexJS.
>
> Looking forward to it,
> -Alex
>
> On 8/28/16, 8:51 PM, "Greg Dove"  wrote:
>
> >Thanks Alex,
> >
> >There are definitely bugs, and I have addressed those that I found in the
> >testbed example I already made a PR for. The others should beWhether I
> >have
> >addressed them appropriately or not I can't say, but if the way I have
> >done
> >things is not consistent with the compiler architecture or any general
> >java
> >coding standards, then at the very least it should provide clues for you
> >or
> >someone else for what needs to be done in a more appropriate way. And if
> >it
> >is unclear why I did anything in particular please ask.
> >
> >One of the things I ended up doing was to move the 'extends
> >EventDispatcher' implementation from ASCompilationUnit to
> >ClassDIrectiveProcessor for falcon and to provide a corresponding
> >implementation in jx. There seemed to be times when that original
> >implementation was not being applied when it ought to have been, and it
> >also seemed like ClassDirectiveProcessor was a more natural home for it,
> >alongside the other 'implements IEventDispatcher' implementation for
> >binding support.
> >
> >
> >In terms of your suggestion about asking questions... I appreciate your
> >intent here, I think most people prefer not to ask stupid questions (even
> >if there is a culture of 'no such thing as a stupid question'), and I
> >needed to get my head around the compiler a bit first before asking too
> >many questions, otherwise most of the questions would probably be stupid
> >ones about how it works!
> >I used this exercise to help me understand the basics, and I personally
> >find this approach is much better for for me to learn anything new over
> >asking lots of questions (it may not be the most efficient to arrive at
> >the
> >knowledge, but it helps me get to a deeper understanding faster I think).
> >Also, although all you guys are great at responding quickly here, I am
> >used
> >to the immediacy of some form of chat, otherwise I am usually already
> >trying to answer my questions myself, particularly if I am already focused
> >on it.  IRC is a good option here that some OS teams use, because it is
> >possible to set up some logging (and therefore can be made searchable, if
> >required). But some people find IRC a bit 'old school' :).
> >
> >I will likely ask more questions in the future, but I do have a more
> >general question now:
> >
> >Also, in terms of changing emitter support in jx for js output, I have not
> >touched anything outside of js emitters - is that usually ok? I don't even
> >know what vf2js or some of the others are for but I do see that some
> >of
> >the various emitter classes have duplicated or similar code in parts of
> >them. I did wonder about whether I was supposed to do anything elsewhere
> >as
> >well, but as I did not really understand it, I chose to stop wondering. :)
> >
> >cheers,
> >Greg
> >
> >
> >
> >
> >On Sat, Aug 27, 2016 at 5:40 PM, Alex Harui  wrote:
> >
> >> Sounds great!  Looking forward to it.
> >>
> >> It might be better in the future if you ask more questions as you go
> >> along.  I think the compiler already does IEventDispatcher although I
> >> wouldn't be surprised if the current code has bugs, so discussing early
> >> can help make sure you are 

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

Hi Greg,

Without a test case to step through the code, I have to say that it is a
bit surprising that you fixed the jx output by fiddling with
ASCompilationUnit and ClassDirectiveProcessor instead of the emitters.

I guess I'll wait to see the PR.  Maybe it will make more sense then.  I
guess maybe you needed to make that change to affect the AST?

Fundamentally, the compiler creates an AST, then Falcon (the SWF compiler)
uses Reducers to reduce the AST to ABC code.  FalconJX uses BlockWalkers
and Emitters.  There are different emitters for different output formats.
The vf2js emitters were an attempt to do a straight cross-compile of the
existing Flex SDK code.  It is not being used by FlexJS.

Looking forward to it,
-Alex

On 8/28/16, 8:51 PM, "Greg Dove"  wrote:

>Thanks Alex,
>
>There are definitely bugs, and I have addressed those that I found in the
>testbed example I already made a PR for. The others should beWhether I
>have
>addressed them appropriately or not I can't say, but if the way I have
>done
>things is not consistent with the compiler architecture or any general
>java
>coding standards, then at the very least it should provide clues for you
>or
>someone else for what needs to be done in a more appropriate way. And if
>it
>is unclear why I did anything in particular please ask.
>
>One of the things I ended up doing was to move the 'extends
>EventDispatcher' implementation from ASCompilationUnit to
>ClassDIrectiveProcessor for falcon and to provide a corresponding
>implementation in jx. There seemed to be times when that original
>implementation was not being applied when it ought to have been, and it
>also seemed like ClassDirectiveProcessor was a more natural home for it,
>alongside the other 'implements IEventDispatcher' implementation for
>binding support.
>
>
>In terms of your suggestion about asking questions... I appreciate your
>intent here, I think most people prefer not to ask stupid questions (even
>if there is a culture of 'no such thing as a stupid question'), and I
>needed to get my head around the compiler a bit first before asking too
>many questions, otherwise most of the questions would probably be stupid
>ones about how it works!
>I used this exercise to help me understand the basics, and I personally
>find this approach is much better for for me to learn anything new over
>asking lots of questions (it may not be the most efficient to arrive at
>the
>knowledge, but it helps me get to a deeper understanding faster I think).
>Also, although all you guys are great at responding quickly here, I am
>used
>to the immediacy of some form of chat, otherwise I am usually already
>trying to answer my questions myself, particularly if I am already focused
>on it.  IRC is a good option here that some OS teams use, because it is
>possible to set up some logging (and therefore can be made searchable, if
>required). But some people find IRC a bit 'old school' :).
>
>I will likely ask more questions in the future, but I do have a more
>general question now:
>
>Also, in terms of changing emitter support in jx for js output, I have not
>touched anything outside of js emitters - is that usually ok? I don't even
>know what vf2js or some of the others are for but I do see that some
>of
>the various emitter classes have duplicated or similar code in parts of
>them. I did wonder about whether I was supposed to do anything elsewhere
>as
>well, but as I did not really understand it, I chose to stop wondering. :)
>
>cheers,
>Greg
>
>
>
>
>On Sat, Aug 27, 2016 at 5:40 PM, Alex Harui  wrote:
>
>> Sounds great!  Looking forward to it.
>>
>> It might be better in the future if you ask more questions as you go
>> along.  I think the compiler already does IEventDispatcher although I
>> wouldn't be surprised if the current code has bugs, so discussing early
>> can help make sure you are spending your cycles appropriately.
>>
>> Thanks,
>> -Alex
>>
>>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

Thanks Alex,

There are definitely bugs, and I have addressed those that I found in the
testbed example I already made a PR for. The others should beWhether I have
addressed them appropriately or not I can't say, but if the way I have done
things is not consistent with the compiler architecture or any general java
coding standards, then at the very least it should provide clues for you or
someone else for what needs to be done in a more appropriate way. And if it
is unclear why I did anything in particular please ask.

One of the things I ended up doing was to move the 'extends
EventDispatcher' implementation from ASCompilationUnit to
ClassDIrectiveProcessor for falcon and to provide a corresponding
implementation in jx. There seemed to be times when that original
implementation was not being applied when it ought to have been, and it
also seemed like ClassDirectiveProcessor was a more natural home for it,
alongside the other 'implements IEventDispatcher' implementation for
binding support.


In terms of your suggestion about asking questions... I appreciate your
intent here, I think most people prefer not to ask stupid questions (even
if there is a culture of 'no such thing as a stupid question'), and I
needed to get my head around the compiler a bit first before asking too
many questions, otherwise most of the questions would probably be stupid
ones about how it works!
I used this exercise to help me understand the basics, and I personally
find this approach is much better for for me to learn anything new over
asking lots of questions (it may not be the most efficient to arrive at the
knowledge, but it helps me get to a deeper understanding faster I think).
Also, although all you guys are great at responding quickly here, I am used
to the immediacy of some form of chat, otherwise I am usually already
trying to answer my questions myself, particularly if I am already focused
on it.  IRC is a good option here that some OS teams use, because it is
possible to set up some logging (and therefore can be made searchable, if
required). But some people find IRC a bit 'old school' :).

I will likely ask more questions in the future, but I do have a more
general question now:

Also, in terms of changing emitter support in jx for js output, I have not
touched anything outside of js emitters - is that usually ok? I don't even
know what vf2js or some of the others are for but I do see that some of
the various emitter classes have duplicated or similar code in parts of
them. I did wonder about whether I was supposed to do anything elsewhere as
well, but as I did not really understand it, I chose to stop wondering. :)

cheers,
Greg




On Sat, Aug 27, 2016 at 5:40 PM, Alex Harui  wrote:

> Sounds great!  Looking forward to it.
>
> It might be better in the future if you ask more questions as you go
> along.  I think the compiler already does IEventDispatcher although I
> wouldn't be surprised if the current code has bugs, so discussing early
> can help make sure you are spending your cycles appropriately.
>
> Thanks,
> -Alex
>
>

Re: [FlexJX][Falcon] Binding support fixes/improvements

[Alex Harui]

Sounds great!  Looking forward to it.

It might be better in the future if you ask more questions as you go
along.  I think the compiler already does IEventDispatcher although I
wouldn't be surprised if the current code has bugs, so discussing early
can help make sure you are spending your cycles appropriately.

Thanks,
-Alex

[FlexJX][Falcon] Binding support fixes/improvements

[Greg Dove]

I thought I should provide a bit of advance notice here...

I had wanted to work on some improvements in the reflection area, and I
have made a start on this (and will certainly get back to it), but I got
quite distracted once I saw that there was still some work left in
Bindings.

I didn't see any branch for work on this, so figured I would take a shot at
some of it.
I have found and fixed a few binding bugs in falcon and added bindable
generation (IEventDispatcher implmentation, same as in swf) and fixed some
things in falcon-jx.

I hope to have pull requests ready for this stuff in a day or two, I am
just working through some related changes in the framework classes, and
want to test it all.
I'd also like to suggest that the asjs codebase gets a BindingTestbed (or
similar) example which could be used to add any examples of what does not
work (commented out until they are fixed). I will have a (very unexciting)
example that could serve as a starting point, but it might be better to add
some real-world stuff.

I don't expect this to make it in for 0.7 release, but just thought I would
give you a heads up so you guys are expecting it.

I've only made changes in a few of the Binding framework classes, there are
others that I haven't touched that might need more work (ViewDataBinding
got some attention, because it was what I was testing with).

Also, this is my first time trying to get my head around the compiler code
(and my java experience is kinda limited) so it probably needs a reasonable
amount of scrutiny when you see the PRs.

cheers,
Greg