Tom Sugden - 11/Aug/09 09:36 AM This sounds very good. The extra line of code required in some cases is justified since it brings a coherent solution for modules, popups, native windows and duplicate in-line components. I have one question: do you think it is always correct to link context lifetime to the presence of a display object on the stage? Although less common, modules sometimes contain non-visual components that are never added to the stage. Also, there are cases when a component may be removed from the stage for performance reasons before being added again later. In my experience, these are usually animating SWFs that would constantly redraw otherwise, however it may also apply to larger contextual components. I think both the above are corner cases which are not vital for 2.1, but you may wish to consider whether the design could accomodate them, in case they become higher priority later on and you still want to preserve backwards compatibility.

Jens Halm - 11/Aug/09 05:19 PM Attaching views is fully optional, so I think this already leaves a lot of options. For a Context that is not view-related you would simply omit the viewRoot DisplayObject parameter. For a Context that is view related, but should not have the lifecycle tied to the removedFromStage event, a bit more work would be required. You could then write a subclass of the builtin ViewManager implementation that just handles the lifecycle differently but otherwise uses the same view wiring mechanism. In theory you could really build a parent-child hierarchy like this: Context A) root Context - attached to mx:Application Context B) module Context, child of A) - not view related Context C) popup within the module, child of B) - attached to mx:TitleWindow The extra steps required in this case are that you have to declare the parent Context for B) and C) manually, as they both would not be able to find it automatically in the view hierarchy. The second thing you'd need to be aware of then is that no component that uses the <parsley:Configure> tag would be attached to Context B) then. It would be either A) or C), depending on its placement in the view hierarchy. If some patterns surface that are needed quite often and not well supported out-of-the-box, I really hope that support for these use cases can be provided within the existing architecture. For example it would be possible to include 3 different builtin ViewManagers in the library at some point so that you just have to switch it in the Context creation tag. But the plan is to just add 1 default impl in 2.1 and then see how people actually use it.