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.2333347.n4.nabble.com/FlexJX-Falcon-Binding-support-fixes-improvemen
ou.
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.247.n4.nabble.com/FlexJX-Falcon-Binding-support-fix
;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.
text:
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.
rowse/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.
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 ha
--
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.
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.
List;
> }
>
> public function set productList(value:ArrayList):void
> {
> if (value != _productList)
> {
> _productList = value;
> dispatchEvent(new Event("propertyChange"));
> }
> }
--
View this message in
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 DataIte
patch 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.
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 a
-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?
Thanks.
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJX-Falcon-Binding-support-fixes-improvements-tp54632p56813.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
>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 f
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 w
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
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 c
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
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 ba
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 co
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 IEven
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
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
"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
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 doe
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
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
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 th
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 t
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
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
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
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;
}
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.dispatch
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. wel
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 a
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,
>t
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
mojo.
Chris
Von meinem Samsung Galaxy Smartphone gesendet.
Ursprüngliche Nachricht
Von: Alex Harui
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 ap
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 EventDispat
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 custo
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 instan
"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
setTargetForT
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 call
d 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
>
>
>
>
>
>
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
ng 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
Gesendet: Mittwoch, 31. August 2016 09:50:08
An: dev@flex.apache.org
Betreff: Re: AW: [FlexJX][Falcon] Binding support
gt; Ursprüngliche Nachricht
> Von: Greg Dove
> 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 lo
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
th
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
>wa
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 i
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.
ch
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 t
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 exa
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
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, a
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 mayb
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
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 a
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
60 matches
Mail list logo
