adi90i7 / as3-commons

Automatically exported from code.google.com/p/as3-commons
0 stars 0 forks source link

method "hasKey" of MapFx cannot be triggered by flex data binding mechanism #44

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.unzip attached zip file.
2.import the project into flash builder
3.compile the project with flex sdk 4.1
4.run the application.

The second checkbox should be selected as I bind it to the method "hasKey" of 
the specified map. but it's not.

I am working with as3commons-collections-1.1.swc on XP with flex SDK 4.1

I also provided a patch in the zip file, hope this can help you.

Thanks,
Edison
hydra1983@gmail.com

Original issue reported on code.google.com by hydra1...@gmail.com on 10 Mar 2011 at 9:03

Attachments:

GoogleCodeExporter commented 9 years ago
A two in one report.

1. Flex apparently looks at the declared type of the bindable reference for 
binding information. In your case IMap (second check box) does not provide any 
bindable properties and is therefore ignored. If you switch your initializer to 
"preinitialize", the check boxes are selected properly. But this is not what 
you want, is it?

2. You are right, the Fx collections do not have binding tags at all. You may 
catch change events with pure ActionScript approach (addEventListener). I will 
consider your feature request in the next bigger update.

Original comment by jens.str...@gmail.com on 16 Mar 2011 at 5:46

GoogleCodeExporter commented 9 years ago

Original comment by jens.str...@gmail.com on 16 Mar 2011 at 5:53

GoogleCodeExporter commented 9 years ago

Original comment by jens.str...@gmail.com on 16 Mar 2011 at 5:54

GoogleCodeExporter commented 9 years ago
Thanks for your reply. Yes, i just want to use the inner binding mechanism to 
get the view updated. I think add the Bindable metadata tag in IMap is a good 
idea no matter the instance is Map or MapFx. When I bind to IMap and 
instantiate a MapFx, I just think the data binding should work because I do not 
instantiate a Map.

Original comment by hydra1...@gmail.com on 17 Mar 2011 at 9:19

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
A work-around for the problem is to create a sub-interface of IMap which is 
annotated with [Bindable], like:

    [Bindable]
    public interface IMapBindable extends IMap{

    }

In addition you need a subclass of Map that dispatches a PropertyChangeEvent 
whenever the map changes.

As long as you declare the variable of type IMapBindable the bindings will work.

Original comment by jostein....@gmail.com on 25 May 2011 at 4:32

GoogleCodeExporter commented 9 years ago
https://github.com/AS3Commons/as3commons-collections/wiki/Roadmap-1.4

Original comment by jens.str...@gmail.com on 26 May 2011 at 8:11

GoogleCodeExporter commented 9 years ago
Hey Guys are you able to fork the project on GitHub, perform changes and submit 
a pull request?

Original comment by jens.str...@gmail.com on 26 May 2011 at 8:21

GoogleCodeExporter commented 9 years ago
Finished.
https://github.com/hydra1983/as3commons-collections
I just implemented everything including in my patch.

Original comment by hydra1...@gmail.com on 27 May 2011 at 3:19

GoogleCodeExporter commented 9 years ago
Where's the bindable-tag? 
https://github.com/hydra1983/as3commons-collections/blob/master/src/org/as3commo
ns/collections/framework/IMap.as

Original comment by jostein....@gmail.com on 27 May 2011 at 7:42

GoogleCodeExporter commented 9 years ago
Here :-)

https://github.com/hydra1983/as3commons-collections/blob/master/src/org/as3commo
ns/collections/framework/IMapFx.as

Original comment by jens.str...@gmail.com on 27 May 2011 at 7:45

GoogleCodeExporter commented 9 years ago
You need on IMap as well, there's no sense in IMapFx being Bindable and IMap 
not. Also, the bindable-tag is to be placed on everything which value's might 
change due to the collectionChange-event.

You need to place it on itemFor as well.

Original comment by jostein....@gmail.com on 27 May 2011 at 7:51

GoogleCodeExporter commented 9 years ago
Each of the collections comes in two versions: A plain and a bindable. The 
reason is simply performance. The majority of use cases utilize non-bindable 
versions.

Original comment by jens.str...@gmail.com on 27 May 2011 at 7:59

GoogleCodeExporter commented 9 years ago
Ah, that's fine. I still want the bindable-tag on itemFor though.

Original comment by jostein....@gmail.com on 27 May 2011 at 9:23

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
..since I want to do this:

<mx:Label text="{myMap.itemFor('foo')}"/>

And myMap is populated by some asynchronous call.

Original comment by jostein....@gmail.com on 27 May 2011 at 10:37

GoogleCodeExporter commented 9 years ago
latest solutions:
#remove IMapFx and IDuplicatesFx

#set [Bindable("collectionChanged")] for IMap and MapFx methods:
* function hasKey(key : *) : Boolean;
* function itemFor(key : *) : *;
* function keysToArray() : Array;

#set [Bindable("collectionChanged")] for IDuplicates and MapFx methods:
function count(item : *) : uint;

Original comment by hydra1...@gmail.com on 27 May 2011 at 12:46

GoogleCodeExporter commented 9 years ago
I think Jens want the IMap-interface free of bindable-tags for performance. 
Looks like you guys got this under control, looking forward to the next release.

Original comment by jostein....@gmail.com on 27 May 2011 at 1:07

GoogleCodeExporter commented 9 years ago
Is there actually any performance hit if no one is binding to those methods?  
Certainly the implementation that supports binding will be less performant as 
it is dispatching events on changes, but I don't see how Binding tag on IMap 
interface actually is affected.

Original comment by hughes.m...@gmail.com on 27 May 2011 at 1:51

GoogleCodeExporter commented 9 years ago
If no one is binding to the methods, they don't need to be bindable in the 
first place.

If you're going to support data binding, Flex goes through all methods 
annotated with Bindable when the event is dispatched and look for clients.

See this article on data binding issues: 
http://www.screenshot.at/blog/2009/04/18/databinding-under-the-hood-part-1-perfo
rmance/

And google "dive into data binding waters" for another presentation on the 
implementation on data bindings.

Original comment by jostein....@gmail.com on 27 May 2011 at 2:12

GoogleCodeExporter commented 9 years ago
@hydra do you mind to check the updated versions using this performance check 
tool?

http://code.google.com/p/sibirjak/source/browse/trunk/#trunk%2Fasperform%2Fcom%2
Fsibirjak%2Fasperform

It should be not more effort than just replace the as3commons collections 
version.

Original comment by jens.str...@gmail.com on 27 May 2011 at 2:29

GoogleCodeExporter commented 9 years ago
So, it's better to create a separate IMapxFx interface to support data binding 
and keep the unbindable IMap? 

By the way, I looked into 
com.sibirjak.asperform.collectiontests.CollectionTests, shoud I run all the 
tests? 

How can I know there is no performance problem with the updated version?

Original comment by hydra1...@gmail.com on 28 May 2011 at 7:57

GoogleCodeExporter commented 9 years ago
this is the performance test results. I run it with flash builder with sdk 3.5 
and have -debug set to false.

Original comment by hydra1...@gmail.com on 28 May 2011 at 8:02

Attachments:

GoogleCodeExporter commented 9 years ago
the results are from the execution of "AS3CommonsTests"

Original comment by hydra1...@gmail.com on 28 May 2011 at 8:04

GoogleCodeExporter commented 9 years ago

Original comment by martin.h...@gmail.com on 12 Sep 2011 at 6:14

GoogleCodeExporter commented 9 years ago

Original comment by martin.h...@gmail.com on 12 Sep 2011 at 6:14