|Published (Last):||10 October 2017|
|PDF File Size:||18.44 Mb|
|ePub File Size:||10.33 Mb|
|Price:||Free* [*Free Regsitration Required]|
This section gives a quick overview over the available features linking to the other chapters of the manual where appropriate. Parsley is a classic IOC Container. The key differentiator is the scope of the framework: While still being as easy to use as many smaller IOC frameworks for simple applications, it also provides many features which are essential for building large, complex and modular applications and numerous extension points.
The core feature of any IOC Container. A feature similar to the concept of Flex Bindings, with the difference that the target does not have to know the source of the binding. The source publishes an object on a property marked with [Publish] and any other object may receive all updates of that value in a property marked with [Subscribe].
Parsley contains a Messaging Framework that allows for objects to send and receive messages in a fully decoupled way. You can mark a function property with the [MessageDispatcher] tag, and invoke it whenever you want to pass a message instance to the system to be routed to registered receivers. The receiving objects can declare interest in particular message types with several metadata tags like [MessageHandler] in a type-safe way.
This is because message selection happens based on the type class of the message, instead of being purely String based like with regular AS3 event handlers. Furthermore messaging can happen in different scopes, globally or just in a particular region like an AIR window for example.
Parsley supports commands based on the standalone Spicelib Commands framework. It allows to execute commands in a way that the container automatically adds them to the Context just for the time they execute. It allows to map commands to messages so that each matching message causes a new command to be instantiated and executed.
Alternatively command factories can get injected into managed objects for manual execution. In this case the container will defer the initialization of other objects until those configured to be asynchronous are ready.
This module is particularly useful for Flex and solves the problem that you usually wouldn't want to declare Flex Components in IOC Container configuration files, but instead inside your MXML view hierarchy like always. Parsley allows to connect these components to the IOC Container on-the-fly when they are added to the stage. For modular applications it's essential that you can create configuration sub-contexts and dynamically load and undload them as needed.
Seamlessly integrates with Flex Modules, but can also be used without. The framework allows for a very fine-grained hierarchy of Contexts, making it convenient to create separate communication spaces for individual windows, popups or tabs in your application. Allows to bind properties to resources with the [ResourceBinding] tag. Parsley can serve as the base for building higher-level frameworks on top of. Or you may just want to create some additional configuration tags for use cases which are frequent for a particular application.
Parsley is easy to extend. Furthermore basically all central services of the IOC kernel can be swapped out easily. This section only lists the parts of the manual which are new or have been signifantly modified. For general migration steps see the next section. Apart from that some APIs have been moved to new packages to improve the internal decoupling of the framework, but these changes only require a simple Organize Imports.
If you followed the Parsley 2 releases you may have noticed that even second digit changes in version numbers often meant breaking API changes. This was because Parsley significantly evolved in its version 2 lifetime based on the growing adoption in large-scale enterprise projects. This fast evolution will come to an end with Parsley 3, where even a future releases of versions 3. Therefore it is strongly recommended to move to Parsley 3 at some point, as it will allow you to benefit from future enhancements and fixes without further changes on your side.
On the other hand Parsley 2 will not see any further enhancement or bugfix releases, so staying with that version would mean that you'd have to find workarounds yourself. Parsley 3 is also the cleanest release to date. With all deprecations being removed and other areas of the code base being streamlined, it is the best version so far for anyone with the intention to learn, enhance or modify the code base.
If your application still uses an older version of Parsley 2, it is recommended to first try to replace the SWCs in your classpath with the ones for the last Parsley 2 release 2. That release contained a lot of deprecation warnings already. Trying to compile against that version might give you a list of deprecation warnings with concrete instructions on what to change.
In Parsley 3 all deprecations have been removed, so you won't get any warnings when compiling against that version. Once you have adjusted your code to remove the warnings and errors you get, you can more easily move to version 3. This section tries to give a detailed overview over the most important changes. If you think that something essential is not covered here, please post on our forum. Only an Organize Import is required to migrate here, with the only exception being some of the lower level options of the ContextBuilder API as covered in the next section.
They are not gone, they are just no longer hard-coded into the ObjectDefinitionBuilder API to make it easier to build custom Parsley distributions with a reduced or different set of pre-installed configuration tags. You do not have to restructure anything, everything can be adjusted via in-place changes.
An example for configuring a message handler via API is shown below:. As you see the message handler is just no longer available through the builder API, but instead comes with a static, standalone entry point.
The biggest area of change in Parsley 3 is the completely rewritten Command Support. The new implementation is not backwards-compatible, although in most cases migration is trivial and possible without touching the command implementation itself only changes in configuration files and classes are required.
If you have an existing application based on Parsley 2 that uses commands a lot, you basically have 2 options:. Once you've decided on the route you want to take, you can find detailed instructions for both approaches below. You can download this extension from the Parsley download page. Depending on what features you have used in your Parsley 2 application, an additional tag in your first ContextBuilder might be necessary:.
The full support for all features listed above would be restored with the following builder:. Once the legacy command support is initialized most of your existing commands should run out of the box.
The few exceptions where usage of some of the more exotic features would need some adjustments are listed below:. If you want to fully migrate your commands you do not have to include the SWC for the legacy command support. Instead you have to apply all the changes listed above which are even necessary when using the legacy command support plus several additional adjustments listed below.
The new version supports many ways to execute a command. Mapping it to a message that triggers command execution is just one of them. In many cases this is just a name change:. But if you also added further configuration for the command with child tags, the syntax needs to change as they can no longer be immediate children of the MapCommand tag.
This is because Parsley 3 also allows the definition of sequences or flows inside MapCommand , so that different child tags can be nested. If you want to configure a single command to be mapped to a message, the following change is necessary:. Finally the names of the execute, result and error method can no longer be changed. It is always the convention to name them execute , result and error respectively.
One option that had been changed is how you can overwrite a result in a result handler inside the command:. If you create the first Context of a Flex application with this API, you need to call the following initialization method once first:.
If you declared a message error handler in Parsley 2, then you need to adjust the order of parameters:. This change has been made to align this tag with all other types of message handlers where the optional processor parameter always comes last.
You can also now additionally map the error handler by message type like with all other types of message receivers:. If you wrote custom configuration tags or other types of extensions, you may need to adjust them one final time. In particular the ObjectProcessor interface has been adjusted one more time. It took some time to get the balance between robustness, flexiblity and simplicity right. This removes the need for cumbersome plumbing, in particular if the processor is stateless.
For a stateful processor you now have to implement the optional StatefulProcessor interface, which adds a simple clone method in case the same processor needs to get applied for another target object. New optional interface StatefulProcessor , extending ObjectProcessor :. This method should create a clone of the processor without any state that you kept for a particular managed object. Although not mandated it was a common pattern to add a static factory method to processors to create a factory for new instances.
With the new optional clone method, a factory is now obsolete. There are also some new options, like using a dedicated PropertyProcessor or MethodProcessor subinterface when implementing processors that just deal with one member of the target instance which is the case for the majority of processors , and convenient target property and method validation as well as the option to specify the exact phase the processor is applied to a target instance in case the order matters. The new options are explained in There are two common use cases where you might want to build the framework's SWC files yourself: either you want to apply a fix or enhancement to a local copy or you want to build snapshots from master to take advantage of fixes or enhancements before they make it into the next official release.
In both cases it's recommended to check out the project from GitHub. This way you can easily follow the ongoing development. Building from source should be pretty straightforward, so this section just gives you a brief summary of the necessary steps. The instructions below apply to all projects, Parsley Core, as well as all Spicelib libraries and Parsley extension projects.
Parsley 3 is hosted on GitHub. If you just want to add something to an official release, it's best to check out the corresponding tag. If you want to follow the ongoing development of the next version and build snapshots you should check out master. Next you have to adapt the properties for your environment, all projects have a template file called build.
Create a copy of that file under the name build. Finally you just have to pick the corresponding Ant target. Projects that just produce one SWC have a single compile target, whereas some projects have multiple targets for compilation.
Parsley and Spicelib get released in a number of separate SWCs. You only have to add the SWCs to your classpath if you need the corresponding functionality.
Spicelib is a set of libraries that do not depend on Parsley and also mostly not on each other. Parsley builds functionality on top of them.
List of Flex frameworks
I decided to break down the Parsley framework for Flex and Flash projects. This is my own minimalist example. I am not going to extol virtues or evils with using Parsley and assume you just want to get a basic example that explains the pieces. It was hard to find a good minimalist starter example that takes the time to explain the details. The Sitronnier blogginglemon examples had other technologies or unneeded features cluttering the code and was devoid of any substantive elaboration. The Sitronnier examples are linked out of the Parsley documentation and are worthwhile bookmarking to review once you get your feet wet.
Subscribe to RSS
Basic Parsley Framework Flex Example Explained
This is the second part in a series exploring Inversion of Control and Dependency Injection containers available for Flex. In the first part of the series we discussed what IoC and DI are and how they can benefit our applications. In this part, we will explore the Parsley IoC Container through a simple image gallery application. Parsley provides several ways to accomplish this. All three mechanisms will be described in the following sections.