2008-12-15: Plans for Parsley 2
Now that Pimento is released our next big step is development of Parsley 2. Since it will be a completely redesigned and rewritten version, we will give you an overview on what to expect from the new version. Development will start in the coming days and Parsley will now be branched in SVN. If you build directly from SVN you should switch to the new v.1.0.x branch. Trunk will contain version 2 now and will be unstable for a while. Since we start from scratch it will be empty initially (except for the small localization module which is the only one that makes it into the new version).
If you are planning to use Parsley 1 in a new project it would probably be better to plan to stick with that version, since migration would involve a lot of redesign and refactoring. We will still provide fixes for critical bugs in the Version 1 branch, even after the version 2 release. But you won't see any new features for upcoming 1.0.x releases.
But now let's explain why there will be a radical shift.
When we first started with Parsley as an inhouse application framework in 2004 it was influenced by Spring 1 and didn't have Flex on the radar since Flex 2 didn't exist back then. For these reasons external XML files were the only option to configure the IOC container. While external files still have their value for certain requirements, we really should offer more. Thus in version 2 you'll be able to use AS3 metadata tags or MXML for configuration, in addition to external XML which will still be supported. There will even be a mode for programmatic container setup if you need to add a lot of logic to your configuration. This new flexibility is the reason that we rewrite the IOC container from scratch. The XML parsing crept deep into the internal APIs so there is no way to continue with this design.
In version 1 extensions for the IOC container could be provided in the form of a custom configuration namespace, either programmatically or with templates. Since external XML is only one of many configuration options in version 2, the templates will be removed. The new extensibility layer will offer more ease of use and more power at the same time. The coolest thing about writing an extension for Parsley 2 will be that if you follow some simple rules you can write a single class as an extension and use it with AS3 metadata tags, MXML and external XML files in your applications.
General purpose messaging architecture
The next thing we'll replace is the MVC framework and the FrontController. While it was easy to use due to its seamless integration into the IOC container, it unfortunately repeated some of the mistakes of other first generation MVC frameworks like Cairngorm or PureMVC, in that it didn't provide a way to completely decouple your application classes from the framework. So while the IOC container was non-invasive, the MVC framework was not. For example you usually had to directly reference the FrontController to be able to dispatch events. The new messaging framework will remove this unnecessary coupling. You could either use regular Flash events, dispatched with a standard Flash EventDispatcher or even use any custom class as a message, sent with a dispatcher function injected into your class by the framework. Classes interested in receiving such a message or event can declare that interest with a simple metadata tag on a method.
The final area for improvements will be explicit support for Flex. Of course every new feature that requires Flex will be included in the separate library so that Parsley can still be used in Flash applications. But there are some areas where Flex simply requires some special attention. We already mentioned one feature: The new option to configure the IOC container with MXML tags. Another feature that will make using Parsley in Flex much smoother is the ability to wire Flex view components with other objects from the IOC container. While in pure Flash applications this usually wasn't an issue since you normally would also declare the view objects in the container, for Flex this approach isn't feasible because it is usually the best approach to declare the view in MXML. With Parsley 2 there will be an easy way to connect views defined in MXML with other objects in the container.
This was just a short summary of what to expect. I think the advantages of the new design will be much clearer as soon as you see some examples in the new manual, which of course has to be rewritten, too. We expect the first release of the new version sometime between late January and March. If you are curious you can follow the development and check out trunk from SVN.