I’m pleased to introduce a new Spring extension called Spring ActionScript. This extension, formerly known as the Prana Framework, is aimed at bringing Inversion of Control to ActionScript along with several other interesting utilities.

The extension is written in ActionScript 3 and is targeted at Flex, AIR and Flash developers. The IoC container and its XML dialect is heavily influenced by that of Spring so it should be easy for developers familiar with Spring to get started with it.

Spring ActionScript contains the following features:
* Inversion of Control container – XML driven, based on Spring
* Reflection API – providing a decent API around describeType()
* Cairngorm extensions – configurable Service Locator, extended Front Controller with command factories, Command chaining, …
* PureMVC extensions – bringing Dependency Injection to PureMVC
* several utilities, assertions, etc

We are also working on the following features, all of which are in an experimental phase:
* MVCS support – providing an architectural framework based on Model-View-Controller-Service
* Domain Driven Design utilities – base classes for entities, value objects, enums, repositories and services
* SqlLite database templates
* Aspect Oriented Programming

The project is currently incubated as we work towards a 1.0 release. The latest available (Prana) release is 0.6 and we plan to release a 0.6.1 version in the coming weeks that introduces the switch to Spring ActionScript.

For more info, please see the following links:

* SVN – https://src.springframework.org/svn/se-springactionscript-as
* FishEye – https://fisheye.springframework.org/browse/se-springactionscript-as
* JIRA: http://jira.springframework.org/browse/SESPRINGACTIONSCRIPTAS
* Forum: http://forum.springframework.org/forumdisplay.php?f=60

Thanks to SpringSource and everyone involved in making this happen!

Hope you enjoy this extension!

More info:
- http://www.theflexshow.com/blog/index.cfm/2008/10/8
- http://www.infoq.com/news/2008/10/prana-framework-actionscript-3

1. don't compile against services-config.xml
2. don't specify destinations on the client

It was with the second goal that I ran into a little issue lately when I was creating an application context for a project that uses BlazeDS. Untill now, I had mostly been using WebORB .Net for Remoting with Flex/AIR and the nice thing is that it offers you a GenericDestination. (AMFPHP offers that too btw) That way, for simple destinations, you don't actually have to specify any destinations in remoting-config.xml. When configuring remote objects on the client, you can set the "destination" property to "GenericDestination" and specify the "source" property. The "source" property then refers to the fully qualified classname of the service you want to invoke.

Here's an example:

It might be interesting to note that there must be a "GenericDestination" defined on the server. So in remoting-config.xml, you would see a destination defined as:

Opposed to a concrete defined destination like:

The wildcard (*) character is replaced at runtime with the value you specify in the "source" property of the remote object.

Switching to BlazeDS however, there is no GenericDestination available. Hm, ok then let's add one. So, I copy the GenericDestination from my WebORB remoting-config.xml to my BlazeDS remoting-config.xml, change my remote objects to specify the GenericDestination and add the source attribute:

BlazeDS will be smart enough to support this...I hope...nope! A ClassNotFoundException is thrown. Apparently BlazeDS is looking for a class named "*" and is unable to handle this.

I might have a look at the BlazeDS sources and try to figure out how this functionality could be added. Or has anyone allready done this, or knows a workaround?

Download | API Documentation | Changelog

In this release the following remarkable changes and additions have been made:

• the IoC container is now ActionScript 3 compatible
• command factories for Cairngorm's FrontController
• more PureMVC experimenting

ActionScript 3 compatibility

We got lots of reactions from people who wanted to use Prana in ActionScript projects but couldn't because Prana relied heavily on some Flex framework specific classes. Well, we have now resolved this issue by completely refactoring the IoC container and parser so that all Flex dependencies are removed. As a result we now have 2 different application context implementations. The first one is the standard XMLApplicationContext which is aimed to be ActionScript 3 compatible. The second one is the FlexXMLApplicationContext which actually extends the XMLApplicationContext and adds support for Flex specific classes like ArrayCollection. The application context and the XML parsers are now configurable with XML node parsers and reference resolvers so it would theoretically be possible now to extend the XML dialect with your own tags and have them parsed by the application context.

Command Factories for Cairngorm's FrontController

In order to reach maximum flexibility in setting up commands and business delegates, we have introduced the option to create custom command factories that plug into Cairngorm's FrontController. The FrontController actually allready acts as a command factory since it takes an event name, looks up its corresponding command and instantiates that command. We have abstracted that behavior so that it is now possible to write a custom implementation of a command factory and register it with the FrontController. This is very handy when you want commands to handle different implementations of business delegates without the need to instantiate a business delegate directly in a command, making it hard to test and change.

What follows is an example of a command that is configured with a business delegate at runtime via the IoC container.

Notice that we are registering the command factory with the FrontController via the "method-invocation" element. This is a new XML element that was introduced this release and that is actually preprocessed to a MethodInvokingFactoryObject.

Further, we are configuring the FrontController with a BusinessDelegateFactory which is available in the Prana Cairngorm extensions. We need to specify a name of the business delegate class we want the factory to create and also pass in a reference to the appropriate service. We also need to make clear to the FrontController what commands need to be created via this factory. As you can see we added 2 types of commands, a AuthenticateUserCommand and a AuthenticateSSOUserCommand.

When the FrontController receives an event, it will look up the corresponding command (just like it works in Cairngorm), but instead of creating a command via its class name on the fly, the controller will lookup the command factory it needs to use and then use that factory to create the command. In the example, a command will be created and a business delegate will be injected.

More PureMVC Experimenting

The Prana-PureMVC team has been playing around with some new ideas around better integration between the two frameworks. Some of the key changes and improvements are:

• changes in internal implementation which are not so much visible from the end user standpoint, but can potentially have some impact on wider prana/puremvc acceptance
• new feature which enables significant reduction of name constants during registration, retrieval and removal of puremvc elements (proxies, mediators and commands)
• new feature which enables additional and different startup idiom with which prana can be initialized late instead of up front as it had to be before

For a full and in depth discussion on these changes, please see the text file at "prana-sample-anotherArch101Demo/resources/docs/pranaPureMvcIntegration-FurtherDevelopment.txt".

Conclusion

We hope you enjoy this release and we are always interested to hear from you. So if you have any comments or suggestions, be sure to join our forum at http://prana.herrodius.com.

Hope you enjoy this release and have fun coding.

Download | API Documentation | Changelog

In this release we further focused on bringing the core Inversion of Control container API closer to that of the well known Spring API. In addition, the release also contains the following:

• an XSD for editing object definition XML files
• application context classes that extend the object factory
• support for external property files to be used in an application context
• support for multiple configuration files
• updated support for PureMVC 2.0.3
• updated samples
• several new utility methods and enhancements to the existing ones
• complete new build system and project layout
• setup wizard to configure prana inside eclipse
• minor bugfixes

Using the XSD

The XML Schema Definition (XSD) is a useful aid in creating object definition XML files. It has the advantage that your object definition XML files will be validated as you create them and a good XML editor will also give you code hinting on the available elements and attributes. In order to use it, make sure you are using an XML editor that has XSD support and place the following in your XML file:

Note: There is a free XML editor available for Eclipse in the Eclipse Europa release. See the Web Tools Platform for more details.

The Application Context

As of this release, we have introduced the concept of the application context. This is actually an extension class of the object factory that offers additional functionality. As a result, we recommend updating your code to use the XMLApplicationContext instead of the XMLObjectDefinitionsLoader.

What follows is an example of how to use the XMLApplicationContext. All samples in this release have been updated to also use the XMLApplicationContext.

Note: There is no support for the <import> tag at this moment.

External Properties

Is some scenarios it might be useful to store certain properties of the config XML file externally so that you can easily change them without having to go through the entire config. The application context now allows you to specify external properties in separate Ant like *.properties files. You can then define property placeholders in your config files with the ${...} syntax.

Here's an example. Note that the path to the *.properties file is relative to the path of the config file.

Building Prana and Setting up your Eclipse Environment

The way the Prana source tree is structured has changed drastically. The new project layout now allows us to create separate branches of the main source tree, the samples and the additional support projects. If you plan on building the sources yourself, please see the prana-install project and the documentation (prana-install/resources/docs/installation-instructions.txt) that contains instructions on how to set it up.

Here's the relevant part of the docs to give you a head start.

- Checkout "prana-install" project from https://prana.svn.sourceforge.net/svnroot/prana/prana-install/trunk
- Checkout other projects that you want to have in your Flex Builder workspace. You don't have to checkout all of them, but you must keep original names ("prana-main", "prana-main-tests" etc.) since a build system relies on them:

https://prana.svn.sourceforge.net/svnroot/prana/prana-main/trunk

https://prana.svn.sourceforge.net/svnroot/prana/prana-main-tests/trunk

https://prana.svn.sourceforge.net/svnroot/prana/prana-sample-cairngormStore/trunk

https://prana.svn.sourceforge.net/svnroot/prana/prana-sample-movieApp/trunk

https://prana.svn.sourceforge.net/svnroot/prana/prana-sample-puremvcArch101Demo/trunk

- Open main build file from "prana-install" project (prana-install/ant/build.xml) and run and "setup-projects" target.
- Answer to questions in GUI wizard.
- Wait until Flex Builder finishes building a workspace.
- That's it. Your workspace should now be fully configured.

To check if everything is set up correctly, you can try some of targets from each project's main build file located in "[project-name]/ant/build.xml".

For example:
- prana-main/ant/build.xml -> "release" target
- this target creates release archives in "prana-main/antbuild/release"
- prana-main-tests/ant/build.xml -> "tests-run" target
- this target runs tests and creates HTML report in "prana-main-tests/antbuild/reports/tests/html"
- prana-sample-[sample-name]/ant/build.xml -> "run-defaultApp" target
- this target runs the sample in a configured browser

If you don't want to checkout the sources from SVN, you can download the prana-projects-0.5.zip file that contains all projects. It is then possible to import those projects in your Eclipse environment. Please see the readme file that comes with the prana-projects-0.5 distribution for more info.

Conclusion

We hope this release will prove valuable to all Flex developers out there. Whether you're just using Prana's utilities, the Cairngorm or PureMVC extensions or the full blown IoC container, there definitely will be something helpful for you.

Don't hesitate to get in touch with the development team and other Prana users via our mailinglist. We appreciate all feedback, be it questions, comments, new ideas or code contributions.

Hope you enjoy this release and have fun coding.

The following sessions will be given:

- Benjamin Dobbler & Stephan Janssen: The creation of Parleys
- Nicolas Lierman: Advanced Flex
- myself: The Prana Framework

For more info, please visit the Flugr website at http://www.flugr.nl/

The basic idea is that we create a factory, let's call it ExerciseFactory, and define a createFromXML() method on it that takes an xml object as its input and "creates" a concrete exercise as its output. The factory is basically an xml parser. It works as follows:

Exercise is the base class for all exercise types like MultipleChoice, FillGaps, etc. The given xml object will be in a format that corresponds to such a concrete type. The factory however needs to know what the given xml is and what concrete exercise type it should return. The easiest way to handle these different xml dialects is with a switch on some property of the xml data. This results in code similar to this (in the ExerciseFactory class):

Although this works, it is certainly bad design since it is code that is hard to maintain and manage. If we need to add or remove some parsers, we have to modify this code which is buried deep inside some package hierarchy. We can't change this behavior at runtime since the parsers are hardcoded into the switch/case.

We could solve this with a mapping configured inside the ExerciseFactory. As its key, it contains the value of the property in the xml data we did the switch on. As its value it contains the class or an instance of the parser. This results in something like the following:

Ok this seems better, but we can't configure the parsers externally since they are coded in the contructor. Let's externalize this by passing in the map to the constructor and additionally create a method for adding a parser.

This is a neat implementation. We're setting a behavior or strategy for the parser in the factory at runtime, based on some configuration. But it has a drawback: the name of the property (xml.someProperty) in the xml data we use as a key in our map always needs to be the same for the different xml dialects. Unfortunately, we can't really control this because a new dialect might be used one day that does not contain the property.

To solve this, let's add another method to our parsers: canCreate(xml:XML):Boolean. As a parameter, it takes the xml data and then checks if it can parse the data by looking into the xml structure. Finally, it returns a boolean indicating whether or not the xml can be parsed. This way, the parser decides for itself what portions of the xml data to check instead of just the one property mentioned earlier.

To force this behavior upon the parsers, we can create an interface, IExerciseParser, and then let every parser implement it:

We can now change the implementation of the ExerciseParser. We will remove the map because we will no longer be checking on a key to get a parser, but the parsers will check for themselves.

... and configure our exercise factory before using it:

What we have achieved now is that we can add new parsers that support new xml dialects without the need to alter the code of the ExerciseFactory. All we need to is create a new parser, let it implement the IExerciseParser interface and it to the ExerciseFactory.

Additionaly, configuring the ExerciseFactory in a Prana application context is a piece of cake:

Hope you enjoyed this. Don't hesitate to leave questions or comments. Have fun coding!

This examples replaces the older Cairngorm Store example that was configured to work with AMF0 and Renaun Erickson's RemoteObjectAMF0. It now uses the latest beta version of AMFPHP and the AMF3 protocol. The services are hosted on this domain so you don't need to setup AMFPHP in order to see this in action.

The code is currently in svn and can be checked out at http://prana.svn.sourceforge.net/viewvc/prana/trunk/samples/PranaCairngormStore/. This sample will also be included in the next release.

Here's a snippet from the readme file:

***

The following files have been added/changed in order to add Prana configuration support for business delegates and service locator:

* Main.mxml: added application context loader and forced compilation of configured classes

package com.adobe.cairngorm.samples.store.business
* BaseBusinessDelegateMock.as: implements IResponderAware, removed responder constructor argument
* CreditCardDelegate.as: extends AbstractRemoteObjectDelegaten, implements ICreditCardDelegate
* CreditCardDelegateMock.as: implements ICreditCardDelegate
* ICreditCardDelegate.as: interface for credit card delegates
* IProductDelegate.as: interface for product delegates
* ProductDelegate.as: extends AbstractRemoteObjectDelegaten, implements IProductDelegate
* ProductDelegateMock.as: implements IProductDelegate

package com.adobe.cairngorm.samples.store.commands
* GetProductsCommand.as: added delegate lookup via ShopModelLocator
* ValidateCreditCardCommand.as: added delegate lookup via ShopModelLocator

package com.adobe.cairngorm.samples.store.model
* ShopModelLocator.as: added creditCardDelegate and productDelegate variables to configure business delegates

***

As a result, we can now lookup the implementation of our business delegates in the commands instead of instantiating new ones. The commands are completely unaware of the implementation of the business delegates. One note though: since we are not creating new delegate instances, we need to set the responder as a property of the delegate before calling its methods.

Here's how the application is configured in the application context to use the mock delegates:

And here's how the remote object delegates and the service locator are configured:

Further, a number of people have blogged about the meeting:
- Ward de Langhe
- Gilles Vandenoostende
- Wim Vanhenden

Some of the key features and updates:

• major update to the core IoC container
• support for PureMVC
• several bugfixes and minor improvements

General info: http://www.pranaframework.org
Download: SourceForge Download Page

Changes in version 0.4 (26.01.2008)
-----------------------------------

General
* introduction of PureMVC support
* added PureMVC sample application
* nightly builds available at http://prana.herrodius.com
* fixed config.xsl to ignore _svn folders

Package org.pranaframework.cairngorm
* fixed early dispatching of events in EventSequence

Package org.pranaframework.collections
* added "remove" method to IMap and Map
* changed "size" and "values" methods to getters
* Map now extends Dictionary instead of Proxy

Package org.pranaframework.config
* AppSettings now extends Proxy instead of Map

Package org.pranaframework.ioc
* added check for valid IList before creating cursor
* added "isLazyInit" and "initMethod" properties to IObjectDefinition and ObjectDefinition
* added support for init method in ObjectContainer
* added "removeObjectFromInternalCache" method
* enhancements to "getObject"
* added post processing capabilities to ObjectContainer

Package org.pranaframework.ioc.factory
* added IObjectContainerAware

Package org.pranaframework.ioc.factory.config
* added ObjectContainerAwarePostProcessor
* added LoggingTargetFactoryObject

Package org.pranaframework.ioc.parser
* added support for lazy init and init method in XmlObjectDefinitionsParser
* fixed "parseProperties" because of Map refactoring, keys were not strings in XmlObjectDefinitionsParser

Package org.pranaframework.puremvc
* initial release

Package org.pranaframework.utils
* added Parse port from the Fit framework
* added HtmlUtils utility methods for working with html
* added "isExplicitInstanceOf" method to ObjectUtils