2011-02-06: Second Milestone of Parsley 2.4 Released
This second milestone is already pretty close to the final 2.4 release in terms of functionality. So if you have an existing application it is recommended to test this milestone now and report any issues so that they can be fixed in time for the final release.
The focus for this milestone centered around two areas, messaging and view wiring. As you'll see the 2.4 version is primarily a polishing release that enhances a lot of the existing features, often primarily with the needs of large and modular applications in mind:
- Deprecate the old MessageInterceptor 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.
- Enhance the 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.
- The default receiver scope can now be changed: 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.
- Support for local command result handlers of 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
MessageSettingsMXML 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.
- 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.
- 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.
- FastInject now removes the dependency from the Context when the view gets removed: When the injected object is configured as a
DynamicObjectit will now get removed when the lifecycle of the view holding the
For the complete list of changes and enhancements you may browse through the Jira tickets for the new release
You can download the new version here.