2011-04-07: Parsley 2.4.0 Final Release
After two milestones released in recent months, the new version is finally ready. Like all Parsley 2 releases with a change in the second digit, it is a bigger update, with significant improvements around reflection performance, several new features and a few internal refactorings.
The version should be fully backwards-compatible for application code and configuration, so it can be used as a drop-in replacement for applications based on Parsley 2.3. For custom extensions it might happen that they need some level of adjustment, as there were a few refactorings in the kernel API, but not nearly as many as for the 2.3 release.
These are the major additions and enhancements for Parsley 2.4, including all features that were already added in the two milestone releases:
- Support for Faster Reflection in Flash Player 10.1: Flash Player 10.1 introduced a new reflection hook that avoids the use of XML like the old describeType function and uses JSON under the hood instead and runs significantly faster. Parsley 2.4 will automatically detect whether this new function is available and prefer this over the old approach and only fall back to XML for older Players. Several tests showed that Context initialization may now often be up to 4 times faster than with version 2.3.
- Support for Multiple Parent Contexts: Previously Parsley only allowed to build a tree-like hierarchy. So while each Context could have multiple children, it always had at most one parent. The new version now allows for an unlimited number of parent Contexts and dependency lookup will be performed in the order you specified the parents until a matching instance is found. This allows to work with a set of "shared Contexts" that represent a set of features which may be required by several, otherwise unrelated modules that all come with their own Context. Future releases may expand on this new feature to offer an OSGi-like Context structure based on manifests that can be used out of the box. But you can start using that functionality today, if you are willing to build some level of infrastructure on top it yourself. For details see Using Multiple Parent Contexts in the manual.
- Support for Persistent Properties: A published property - using the
[PublishSubscribe]metadata (or MXML or XML) tag - can now be marked as persistent. Immediately after the object gets instantiated it will then receive the value from the last time the application ran. Under the hood Parsley uses Local SharedObjects for storing the values. But this is only the default implementation which can be swapped like almost everything in Parsley. For details see this new section in the manual
- New Approach for Message Interceptors: The old MessageInterceptor tags were deprecated in favor of a new system that offers more flexibility. Now every normal message receiver like a MessageHandler or CommandResult for example can act as an interceptor if it declares an additional, optional method parameter of type MessageProcessor. See the corresponding section in the manual for details.
- Enhanced MessageProcessor Interface: This interface which is used in message interceptors is now more powerful through the addition of a few new methods like
sendResponse. The latter dispatches a message through the Context the received message originated from.
- New Option to Change the Default Receiver Scope for Messages: Previously the default for all message receiver configurations was to use the
globalscope if none was specified explicitly. This made configuration in large and modular applications unnecessarily verbose as those tend to use the
localscope much more often than the
globalscope. The scope can be set with the new
defaultReceiverScopeattribute of the
<MessageSettings>tag or API, either globally or for a particular Context (and its children) only.
- Type-Safe Selectors for Messages: Previously a selector could only be declared as a string in metadata or XML (you could already use other types when declaring it in MXML in previous versions). With the new version you can now optionally declare the selector as a second parameter of the message handler if it is not just string-based. This way you can match by two types: The type of the message and the type of the selector.
- FastInject API: Previously only available as an MXML tag, now also with a fluent API for use in ActionScript Components or Flash Applications. See The FastInject API in the manual for details.
- Configure API: Like with FastInject previously only available as an MXML tag, now also with a fluent API for use in ActionScript Components or Flash Applications. See Explicit Component Wiring in the manual for details.
List of smaller additions and enhancements that make your life easier:
- Configuration Properties Inherited by Child Contexts: The new Configuration Properties introduced in version 2.3 are now inherited by child Contexts. Previously they were only available for the one Context they were loaded into, so that they had to be loaded multiple times if they were needed in more than just one Context.
- Local Command Result Handlers for Global Commands: This again supports a common pattern in large applications. A message gets dispatched by a module and then processed by a shared service (command) in the root Context. The command itself must listen to the
globalscope to receive the message, but very often only the module (or tab or window) that sent the message is interested in receiving the result. Such a module can now declare a
localscope which will get invoked when the same Context had sent the message that triggered the command.
- Support for Custom ViewProcessors: Previously the views were always added to the Context when using View Autowiring. But that in turn leads to reflection on the view which is often better to avoid in large applications due to the cost of reflecting on those heavy objects that extend
UIComponent. The primary alternative that avoided reflection was
FastInject, but that is explicit and not automatic. With a custom
ViewProcessorthe automatic wiring capability can now be combined with any kind of (light) processing on the view. See Custom View Processors for Autowiring in the manual for details.
- Support for Custom ViewLifecycles: Previously there were basically two options which could be picked by a configuration flag on the
ViewSettingsMXML tag or API. The default controlled the lifecycle of views based on the time they are on the stage, the alternative listened for a custom event. This new hook allows to install custom lifecycles per view type. This allows to change the behavior for components that require special treatment. See Custom Lifecycle Handlers in the manual for details.
- New Option for the <Configure> tag: Now you can add child tags to this MXML tag representing the objects that should get added to the Context (e.g. the presentation model) instead of the view that contains the tag itself. See Explicit Component Wiring in the manual for details.
- Automatic Cleanup for FastInject: When the injected object is configured as a
DynamicObjectit will now get removed from the Context automatically when the lifecycle of the view holding the
List of internal improvements for increased robustness, simplicity and efficiency:
- Simplified Support for Flex Modules: Versions 2.1 to 2.3 installed a wrapper around the original Flex ModuleManager. While this worked reasonably well, it turned out to be unnecessary complexity, as the major goal for that wrapper was to detect and remember the ApplicationDomain to use for each Context getting built. This task is now performed by a much simpler service, which can also be replaced. The default implementation looks for the moduleFactory property of the first view root for each new Context and retrieves the domain from there. In Flash Applications the default looks for the
viewRoot.root.loaderInfoproperty. If any of the automatic approaches does not work, the ApplicationDomain can still be specified explicitly like in previous versions.
- Redesigned Context Bootstrap Service: This change primarily affects developers writing extensions. While the other 6 IOC kernel services are already stabilizing and only saw minor changes in version 2.4, one of the 7 kernel services needed a larger refactoring (basically a rewrite). The old
CompositeContextBuildergets deprecated and replaced by a new
BootstrapManagerwhich more cleanly offers one central hook for all bootstrap configuration which is now also completely inherited from parent Context to child Context. The new home for global defaults is now
BootstrapDefaults.config, replacing the old
GlobalFactoryRegistrywhich is still (partially) available for backwards-compatibility.
The final release of version 2.4 will be followed by one or at most two maintenance releases, depending on how many issues will surface. Version 2.4 will be the last major update to Parsley 2. After the maintenance releases, development of version 3 will start, with first milestones expected this summer. A separate news entry will be posted in the coming weeks that will summarize the plans for the new version.
You can download the new version here.