How to Submit a Feature?

Thanks a lot Vera, good to know.

There's "more than 3 less than 10" things that I cannot do by subclassing things.  If I could use modules like in Ruby, it'd be easy.  Here are some of the things:

1) Refactoring the LayoutBase so it supports modifying the individual position/rotation "tokens" for each layout element.  So you could easily turn a VerticalLayout into a StepLayout or an ArcLayout without subclassing anything.

2) Ability to pass data to IFactory instances, so we can pass data to ItemRenderers without using inline components (which are hard to debug).

3) Refactoring the StyleManager so it supports nested styling in Skins, to promote code reuse and to make skinning a million times faster/easier.

4) Refactor event dispatching in accessors for Binding, so events aren't unnecessarily dispatched, while also considering shutting off event dispatching temporarily if desired (manually, like during animations).

5) Refactoring all event handling into Controller objects, and creating a "controllers" property on the UIComponent that attaches controllers to it (following OpenFlux).  This allows you to only use what you need, while the defaults are built in.  And most importantly, it favors composition over inheritance: I've seen lots of people showing sample Spark apps saying how easy it is to create components and layouts, and they are just extending the objects and adding new "controller" functionality.  This is going to quickly become a mess.  If Spark has figured out Component Architecture, then there shouldn't ever be a need to extend the core components, you just create a controller for it.  That philosophy is working 100% of the time right now.  You only need a new component when it has totally different functionality (i.e. don't extend the TextArea into an EditableTextArea, an ExpandableTextArea, and an UndoableTextArea, just have a TextArea with 3 controllers).

6) Metadata API for custom metadata processing, like the DescribeTypeCache does for Bindable, but for custom ones.  Maybe a MetadataManager.

With the controller architecture it is simple to automate effect generation in the skins, without having to write things for every single one.  I just have a StateController that listens for state changes (set as a default controller on a SkinnableComponent), and plays an effect on the property, whatever it is.  That means from CSS you can do crazy animations on everything in the skin without having to write any code.

With the controller architecture, too, you can massively apply effects to things like the layout, especially if you had access to the layout element position/rotation token.  You could easily animate between layouts like that.  LiquidLayouts and all the AdvancedLayoutFeatures still work with this.

But for all this I need to access the core components.  I've started building an alternative to Flex, integrating Spark and Openflux ideas, because I didn't realize you could commit like this, so hopefully I don't have to finish ; ).  That's I guess the whole point of it being open source, but it's a little hard to get started since absolutely nobody is talking about it .

Best,

Lance