bindings, lists and projects

1 view
Skip to first unread message

Tyler Wright

unread,
Oct 10, 2009, 1:52:15 PM10/10/09
to reflex-steer...@googlegroups.com
First a comment on lists: in Flex lists and collections are quite a large infrastructure. The tendency is to lump all of its features together, even when discussing our own implementation. However, having a simple List or Array Proxy for basic notification when changes occur is an essential part of data binding, and does not need to include sorting, views and other collection complexities. Having a good, light solution for bind-friendly arrays is essential for a non-Flex component set.

Non-Flex binding, lists and a few other basic utilities are core to many systems, not just our components. A couple of application frameworks (Flight Framework and Robot Legs) hope to have these solutions to remain Flex independent, and I think there are other libraries and projects that would benefit from these common solutions.

I propose we remove binding from the Flight Framework where it currently resides and create an AS3 commons that contain some of these most basic features. Reflex, Flight and others would be dependent on this common library. Does anyone see problems with this solution or do you think it would be the best route?

Tyler

James Ward

unread,
Oct 11, 2009, 11:42:41 AM10/11/09
to reflex-steer...@googlegroups.com
I think that's a great idea. Promoting some kind of Apache Commons type
of community for core libraries is a good direction. We can also use
this methodology of using these common libs (and many of the others out
there) a core part of Reflex.

I just wish there was a central place for all of these common libs (like
there is with Java on Apache). Oh well.

-James

Ben Stucki

unread,
Oct 12, 2009, 9:52:20 PM10/12/09
to reflex-steer...@googlegroups.com
I like the idea of seeing common pieces of code reused across open-source projects (and who doesn't), but I think it would be difficult to do practically. The problem is that everybody's expectation are very different on what belongs in it and how it should be implemented. For example there's as3corelib which has been pretty successful at implementing low-level functionality that the player is capable of but missing directly. They might argue, however, that binding would never be a "core" player feature and doesn't belong in the library. Other projects like AS3Commons might like to see binding as part of a common library, but ideally we would use their common code for things like reflection - which we probably won't do because of the size constraints we're placing on ourselves. Again, we run into different expectations. The bottom line is we could setup yet another commons library project, but there's no guarantee anyone else will find the approach suitable for their project. I would argue that we wait for someone else to lead the charge, and contribute wherever we can - just my 2 cents.

- Ben

Tyler Wright

unread,
Oct 13, 2009, 4:11:15 PM10/13/09
to reflex-steer...@googlegroups.com
For now I will keep the code in the Flight package, which is already a core library of classes and utilities with 1 additional package of Application logic. I've put the relevant classes in my 'behaviors' branch of my reflex GIT repo and will merge them over once we're happy with the idea of the extra classes in the master branch.

Some day reflex will be that core lib anyway as the Future of RIA. ;)

Tyler

side-note: as3common's reflection is too heavy, you're right. I think E4X is already a great object structure that makes it easy to search and pull out data you need, why build another object structure on top of that? Speaking of E4X, do we know that FP10.1 fixed the memory leaks there?
Reply all
Reply to author
Forward
0 new messages