I find it similar to the Parsley (http://www.spicefactory.org/parsley) project, in the sense that they don't claim to be an architecture, but rather a collection of tools:
Operation API - based on Flex classes, and is basically identical to the delegate actor in Cairngorm.
event bus - same publish/subscribe idea as in any Flex framework
autoWiring - nice, but I wonder what's the level of flexibility you have as oposed to creating your own custom metadata tags
The foundations are good. You get an IoC container on your Flex client side to manage assembly, scopes, events, etc.
When you create your own wiring mechanism you'll probably tailor it to fit your application's needs (unless you have the time and budget to create a general purpose library). However, requirements tend to grow as the project evolves and one day you might find yourself dealing with features-set improvement and bug fixing (or general maintenance) of this framework when the same time and effort should be put into business concerns.
I usually prefer to trust such frameworks (especially when they grow under the SpringSource umbrella).
BUT(!) As I was following this ideology in my current project I realized that this frameworks isn't something I can count on (I started using it on version 0.6 and found myself struggling with bugs, little community help, and no time to spend on debugging it). So I ended up wiring the components on my own... However, I have an open task - "throw away own wiring and put Spring back to work". So, I'm gonna give another try in the near future.
Comments
Interesting.
I find it similar to the Parsley (http://www.spicefactory.org/parsley) project, in the sense that they don't claim to be an architecture, but rather a collection of tools:
Operation API - based on Flex classes, and is basically identical to the delegate actor in Cairngorm.
event bus - same publish/subscribe idea as in any Flex framework
autoWiring - nice, but I wonder what's the level of flexibility you have as oposed to creating your own custom metadata tags
The foundations are good. You get an IoC container on your Flex client side to manage assembly, scopes, events, etc.
When you create your own wiring mechanism you'll probably tailor it to fit your application's needs (unless you have the time and budget to create a general purpose library). However, requirements tend to grow as the project evolves and one day you might find yourself dealing with features-set improvement and bug fixing (or general maintenance) of this framework when the same time and effort should be put into business concerns.
I usually prefer to trust such frameworks (especially when they grow under the SpringSource umbrella).
BUT(!) As I was following this ideology in my current project I realized that this frameworks isn't something I can count on (I started using it on version 0.6 and found myself struggling with bugs, little community help, and no time to spend on debugging it). So I ended up wiring the components on my own... However, I have an open task - "throw away own wiring and put Spring back to work". So, I'm gonna give another try in the near future.