Tom Sugden - 11/Aug/09 09:51 AM This looks tidy and CompositeContext tag is great. Might it be useful for these components to dispatch complete and fault events, so that in-line event handlers can be specific in MXML?

Jens Halm - 11/Aug/09 06:31 PM They actually must dispatch those events because for convenience the tags themselves will implement the Context interface (and then internally delegate to the real Context they create). So they'll dispatch all events declared in the Context interface.

Jens Halm - 11/Aug/09 08:08 PM Just realized that it is probably not a good idea if they implement the Context interface. There would be some confusing overlap of properties from the Context interface and the properties you need to specify for the builder. In any case they will dispatch ContextEvent.CONFIGURED, INITIALIZED and ERROR.

Tom Sugden - 04/Jan/10 11:05 PM If the config property is typed as Class, you can avoid bindings (and import statements) by specifying the qualified class-name: <parsley:FlexContext config="a.b.MyConfig"/> Then the property value is set before initialized gets called on the IMxmlObject and you still get compile-time type checking. I suppose it's a little brittle, since there's nothing to stop users from still using bindings. I noticed the Swiz 1.0.0 alpha release uses a Timer to wait for bound properties to be set. On my current project, we already implemented our own configuration tags similar to those on the roadmap. We also defined a few convenience methods that delegate to the underlying context, such as add/removeViewRoot().

Tom Sugden - 04/Jan/10 11:15 PM Just had a look at the implementation in trunk. The new tags look good. We used the composite approach, like in the roadmap, but that was a little awkward to implement and I prefer your approach of a ContextBuilder with children for the different "parts" of the context.

Jens Halm - 05/Jan/10 12:25 AM - edited Unfortunately the road map chapter is currently totally out-of-sync. The features are all implemented now in trunk and while working on it I realized that none of the original specs felt 100% right. I'll release a snapshot for 2.2 this weekend (with the final release scheduled for two weeks later) and will update the road map chapter so that everyone knows how to use and test these features. Regarding bindings in MXML tags: I think it is possible to reliably support them. The 2.1.1 release already contained an improvement for the Configure tag that now makes the target property work reliably. The tag now extends ConfigurationTagBase which the new ContextBuilder tags will also extend. When you look at the code for the base class, you'll see how I try to synchronize for a number of scenarios. Through 2 boolean flags as constructor params you can instruct the tag to A) wait until the document object is added to the stage and B) wait until the component dispatched its FlexEvent.INITIALIZE event, or both. My tests showed that after FlexEvent.INITIALIZE one can safely assume that bindings have been executed. A timer like in Swiz sounds fragile to me.

Tom Sugden - 05/Jan/10 11:43 PM Another approach is seen in Flicc, where the ObjectFactory (a.k.a. the Parsley MXML config) is declared in MXML: <flicc:FliccListener>    <ab:MyFactoryConfig/> </flicc:FliccListener> This feels clean and avoids bindings, but does change responsibilities a little, since Parsley usually instantiates the config class itself. The Swiz 1.0.0 alpha has adopted the same approach now, where BeanProviders are declared inside a Swiz instance.