2012-02-06: Parsley 3.0.0 Final Release
After two milestones released earlier this year, Parsley 3.0 is now final. It is a major update that comes with a few bigger feature additions, refined extension APIs and a new project structure that delivers part of the functionality in separate extension projects.
The following lists give a quick overview over all changes, including those already delivered in the two milestones.
- Support for Groups of Managed Commands: Declare a group of commands for sequential or parallel execution in MXML, XML or programmatically and let the container automatically add them to the Context only for the time the command executes.
- Support for Command Flows with Dynamic Decision Points: Declare a dynamic flow of commands in MXML, XML or programmatically where the next command to execute is determined based on a rule set applied to the result of the command.
- Support for Passing Data to Execute Methods of Commands: Any result of a preceding command in a group or flow or any data specified before starting the group can be passed to the execute method of a command. The injection is performed by type, turning the command framework into some kind of mini-IOC container, even when used without Parsley, as the core command support is based on the standalone Spicelib Commands project.
- Support for Mapping Commands to Messages: A feature already available in the old DynamicCommands in Parsley 2, now adjusted to the new functionality, allowing to not only map single commands, but alternatively also groups and flows of commands to messages. The mapping can be declared in MXML, XML or programmatically.
- Explicit Command Execution: In contrast to the old DynamicCommands that only offered managed commands that were triggered by a message, the new command support alternatively allows to explicitly execute a command while still benefiting from the general support for managed commands. Execution can be triggered in an entirely programmatic way or based on a command factory declared in MXML or XML and injected into any managed object.
- Increased Flexiblity for Different Command Types: The command type based on an AsyncToken return type in the execute method like predominantly used in Parsley 2 is now only one of many options. Any kind of asynchronous operation can now easily be implemented, often by simply invoking a callback function passed to the command to signal the completion and pass the result to the framework for further processing.
- Parsley 2 Backwards Compatibility Layer: The new command support replaces both, the old DynamicCommand feature and the old Spicelib Task Framework. Existing applications that still need this functionality in cases where migration would be too risky or too costly can install the legacy extensions for the two features that retain most of the old functionality.
New Project Structure
- Move to GitHub: All active Spicefactory projects are now hosted on GitHub.
- Extracting Optional Features into separate Extension Projects: If you browse the repositories on GitHub you'll notice that there are now a lot of separate projects. The Spicelib libraries are now all released separately as they really do not depend on each other. And there is a new Parsley Core project that covers roughly 80% of the funcitonality of Parsley 2, while other features which are considered optional and also introduce additional dependencies have been extracted into extension projects. There are currently four extensions, one for XML configuration tags for logging, one for the Cairngorm Popup support, one for the old Localization Framework for Flash applications and finally one for configuration support for Pimento and Cinnamon.
- Final Extension APIs: After several changes in the Parsley 2 lifetime, the Extension APIs now got their final set of changes. The new API is intended to be a long-term stable API. The final changes made creation of object processors which usually do the work for custom configuration tags easier and more flexible and further decoupled the individual features.
- Built-in Tags Optional: Due to the refactoring of the Extension APIs all built-in configuration tags like those for injection and messaging can now be disabled, allowing for the creation of a highly customized alternative feature set.
- Repackaging: Several APIs have been moved in Parsley 3. MXML, XML or metadata configuration tags are not affected by these changes, but if you used one of the configuration APIs you may need to adjust your imports.
- Removal of all Deprecations: All classes, properties and methods marked as deprecated in the Parsley 2 lifetime have now been removed. The core framework is much cleaner and more robust without the need to support huge legacy APIs.
- New Options in ViewSettings Tag and API: The ViewSettings now come with a new
autodestroyContextattribute to control the default behaviour for an entire Context and its children. Previously the reuse option had to be specified for each wired view individual and the Context destruction policy could not be controlled at all.
- Event Callbacks in ContextBuilder API: Makes programmatic Context creation more convenient and concise.
- Parallel AsyncInit Processing: When multiple objects that are marked as
AsyncInithave the same order attribute, they are now initialized in parallel, speeding up the Context startup for these cases.
- Several Bugfixes: Parsley 3 also contains a lot of fixes for issues that surfaced in Parsley 2.4, as documented in Jira.
The manual for the new version contains a detailed Migration Guide. Please report back in the forum when you think that anything essential is missing.