Apr 20

Prana Framework 0.5 Released

ActionScript, Flex, Inversion of Control, Prana 5 Comments »

I'm pleased to announce that the Prana Framework 0.5 release is now available.

Prana

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:

PLAIN TEXT
XML:
  1. <objects xmlns="http://www.pranaframework.org/objects"
  2.          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  3.          xsi:schemaLocation="http://www.pranaframework.org/objects http://www.pranaframework.org/schema/objects/prana-objects-0.5.xsd ">

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.

PLAIN TEXT
Actionscript:
  1. // load a single 'applicationContext.xml' config
  2. var applicationContext:XMLApplicationContext = new XMLApplicationContext("applicationContext.xml");
  3. applicationContext.addEventListener(Event.COMPLETE, onApplicationContextComplete);
  4. applicationContext.load();
  5.  
  6. // load multiple config files
  7. var applicationContext:XMLApplicationContext = new XMLApplicationContext(["applicationContext-1.xml", "applicationContext-2.xml"]);
  8. applicationContext.addEventListener(Event.COMPLETE, onApplicationContextComplete);
  9. applicationContext.load();

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.

PLAIN TEXT
XML:
  1. // in a file called strings.properties
  2. s1=First string
  3. s2=Second string
  4.  
  5. // in the config file
  6. <objects>
  7.  
  8.   <property file="strings.properties" />
  9.  
  10.   <object id="string1" class="String">
  11.     <constructor-arg value="${s1}"/>
  12.   </object>
  13.  
  14.   <object id="string2" class="String">
  15.     <constructor-arg value="${s2}"/>
  16.   </object>
  17.  
  18. </objects>

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.

Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 
Mar 14

Combining Factory and Strategy patterns

Design Patterns, Inversion of Control, Prana 4 Comments »

We often run into a scenario at work where we have to create an object from xml. More specifically we are parsing xml files with exercise (or assessment item) data to a concrete exercise type like a MultipleChoice, FillGaps, HotSpot, etc. The thing is that we are supporting several xml dialects for the same type of exercise and we end up with a lot of parsers. On top of that we also need to be able to decide on a per project basis what xml dialects are supported (a customer may only be allowed to use dialext X for exercise Y). In the next lines I will try to explain the way we manage and configure the objects that are involved in this process.

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:

PLAIN TEXT
Actionscript:
  1. var exerciseFactory:ExerciseFactory = new ExerciseFactory();
  2. var exercise:Exercise = exerciseFactory.createFromXML(xml);

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):

PLAIN TEXT
Actionscript:
  1. public function createFromXML(xml:XML):Exercise {
  2.   var result:Exercise;
  3.   switch (xml.someProperty) {
  4.     case multiplechoice-dialect-a:
  5.       // parse type MultipleChoice with dialect a
  6.       break;
  7.     case multiplechoice-dialect-b:
  8.       // parse type MultipleChoice with dialect b
  9.       break;
  10.     case multiplechoice-dialect-c:
  11.       // parse type MultipleChoice with dialect c
  12.       break;
  13.     case fillgaps-dialect-a:
  14.       // parse type FillGaps with dialect a
  15.       break;
  16.     case fillgaps-dialect-b:
  17.       // parse type FillGaps with dialect b
  18.       break;
  19.     default:
  20.       throw new Error("Cannot create exercise for the given xml object.");
  21.   }
  22.   return result;
  23. }

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:

PLAIN TEXT
Actionscript:
  1. public function ExerciseFactory() {
  2.   this.map = {};
  3.   this.map[multiplechoice-dialect-a] = new MultipleChoiceDialectAParser();
  4.   this.map[multiplechoice-dialect-b] = new MultipleChoiceDialectBParser();
  5.   this.map[fillgaps-dialect-a] = new FillGapsDialectAParser();
  6. }
  7.  
  8. public function createFromXML(xml:XML):Exercise {
  9.   var parser:ExerciseParser = this.map[xml.someProperty];
  10.   return parser.parse(xml);
  11. }

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.

PLAIN TEXT
Actionscript:
  1. public function ExerciseFactory(map:Object) {
  2.   this.map = map;
  3. }
  4.  
  5. public function addParser(key:String, parser:ExerciseParser):void {
  6.   this.map[key] = parser;
  7. }
  8.  
  9. public function createFromXML(xml:XML):Exercise {
  10.   var parser:ExerciseParser = this.map[xml.someProperty];
  11.   return parser.parse(xml);
  12. }

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:

PLAIN TEXT
Actionscript:
  1. public interface IExerciseParser {
  2.   function canParse(xml:XML):Boolean;
  3.   function parse(xml:XML):Exercise;
  4. }
  5.  
  6. public class MultipleChoiceDialectAParser implements IExerciseParser {
  7.   public function canParse(xml:XML):Boolean {
  8.     // check the xml structure
  9.   }
  10.   function parse(xml:XML):Exercise {
  11.     // parse the xml to a MultipleChoice
  12.   }
  13. }
  14.  
  15. public class MultipleChoiceDialectBParser implements IExerciseParser {
  16.   public function canParse(xml:XML):Boolean {
  17.     // check the xml structure
  18.   }
  19.   function parse(xml:XML):Exercise {
  20.     // parse the xml to a MultipleChoice
  21.   }
  22. }
  23.  
  24. public class FillGapsDialectAParser implements IExerciseParser {
  25.   public function canParse(xml:XML):Boolean {
  26.     // check the xml structure
  27.   }
  28.   function parse(xml:XML):Exercise {
  29.     // parse the xml to a FillGaps
  30.   }
  31. }

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.

PLAIN TEXT
Actionscript:
  1. public function ExerciseFactory(parsers:Array) {
  2.   this.parsers = parsers;
  3. }
  4.  
  5. public function addParser(parser:IExerciseParser):void {
  6.   this.parsers.push(parser);
  7. }
  8.  
  9. public function createFromXML(xml:XML):Exercise {
  10.   var result:Exercise;
  11.   for (var i:int = 0; i<this.parsers.length; i++) {
  12.     var parser:IExerciseParser = this.parsers[i];
  13.     if (parser.canParse(xml)) {
  14.       result = parser.parse(xml);
  15.       break;
  16.     }
  17.   }
  18.   if (!result) {
  19.     throw new Error("Cannot create exercise for the given xml object.");
  20.   }
  21.   return result;
  22. }

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

PLAIN TEXT
Actionscript:
  1. var exerciseFactory:ExerciseFactory = new ExerciseFactory();
  2. exerciseFactory.addParser(new MultipleChoiceDialectAParser());
  3. exerciseFactory.addParser(new MultipleChoiceDialectBParser());
  4. exerciseFactory.addParser(new FillGapsDialectAParser());

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:

PLAIN TEXT
XML:
  1. <objects>
  2.   <object id="exerciseFactory" class="ExerciseFactory">
  3.     <constructor-arg>
  4.       <array>
  5.         <object class="MultipleChoiceDialectAParser"/>
  6.         <object class="MultipleChoiceDialectBParser"/>
  7.         <object class="FillGapsDialectAParser"/>
  8.       </array>
  9.     </constructor-arg>
  10.   </object>
  11. </objects>

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

Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 
Feb 24

Prana enabled Cairngorm Store

ActionScript, Cairngorm, Flex, Inversion of Control, Prana 8 Comments »

Following up on Douglas McCarroll's modified Cairngorm Store update, I thought I'd take this a step further and add a Prana application context to configure the business delegates and the service locator. This example has support for mock delegates that contain hardcoded local data and is also able to connect to php services using Remote Objects and AMFPHP.

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.

PLAIN TEXT
Actionscript:
  1. var delegate:IProductDelegate = ShopModelLocator.getInstance().productDelegate;
  2. delegate.responder = this;
  3. delegate.getProducts();

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

PLAIN TEXT
XML:
  1. <object id="shopModelLocator" class="com.adobe.cairngorm.samples.store.model.ShopModelLocator" factory-method="getInstance">
  2.     <property name="creditCardDelegate">
  3.         <object class="com.adobe.cairngorm.samples.store.business.CreditCardDelegateMock"/>
  4.     </property>
  5.     <property name="productDelegate">
  6.         <object class="com.adobe.cairngorm.samples.store.business.ProductDelegateMock"/>
  7.     </property>
  8. </object>

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

PLAIN TEXT
XML:
  1. <object id="endPoint" class="String">
  2.     <constructor-arg value="http://www.herrodius.com/amfphp/gateway.php"/>
  3. </object>
  4.  
  5. <object id="serviceLocator" class="org.pranaframework.cairngorm.CairngormServiceLocator" factory-method="getInstance">
  6.     <property name="productService">
  7.         <object class="mx.rpc.remoting.mxml.RemoteObject">
  8.             <property name="destination" value="GenericDestination"/>
  9.             <property name="endpoint">
  10.                 <ref>endPoint</ref>
  11.             </property>
  12.             <property name="source" value="com.adobe.cairngorm.samples.store.business.ProductService"/>
  13.         </object>
  14.     </property>
  15.     <property name="creditCardService">
  16.         <object class="mx.rpc.remoting.mxml.RemoteObject">
  17.             <property name="destination" value="GenericDestination"/>
  18.             <property name="endpoint">
  19.                 <ref>endPoint</ref>
  20.             </property>
  21.             <property name="source" value="com.adobe.cairngorm.samples.store.business.CreditCardService"/>
  22.         </object>
  23.     </property>
  24. </object>
  25.  
  26. <object id="shopModelLocator" class="com.adobe.cairngorm.samples.store.model.ShopModelLocator" factory-method="getInstance">
  27.     <property name="creditCardDelegate">
  28.         <object class="com.adobe.cairngorm.samples.store.business.CreditCardDelegate"/>
  29.     </property>
  30.     <property name="productDelegate">
  31.         <object class="com.adobe.cairngorm.samples.store.business.ProductDelegate"/>
  32.     </property>
  33. </object>

Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 
Jan 29

Prana Presentation Slides

ActionScript, Conferences, Inversion of Control, Prana No Comments »

I put up the slides of the Prana presentation I did on the Adobe Usergroup - AIR Pre-Release Tour. You can download them at the Talks section or here (direct download).

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

Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 
Dec 30

Porting the Spring IoC core to Prana

ActionScript, Flex, Inversion of Control, Prana 2 Comments »

I decided that, for the benefits of Prana, it would be better to port the core of the Spring IoC container as much as possible instead of developing further on an own implementation. Although the XML dialect for the application contexts is already similar to that of Spring(.net), and hence familiar to a lot of developers, the core code isn't.

When I started the Prana project I decided to create my own, much simpler, implementation because I was afraid that many developers would be scared away by the much bigger codebase of the IoC container. On top of that, the Spring core is a massive amount of code so it was easier for me to understand the ideas behind everything and create a much simpler implementation than to find my way through the jungle and port every line of code.

However as I progress in the development of Prana and get to know more about Spring, there are numerous reasons that the Prana core could actually benefit from being much more like that of Spring.

Here are the main motivations:

- Get started quickly as a Spring developer: Spring developers already know how the IoC container works and what is possible with the API. They don't need to learn a new API to start working with Prana. That is with a few exceptions though, e.g. the async loading of application contexts.

- Make Flex developers familiar with Spring: If you don't know Spring as a Flex developer, working with Prana will get you introduced to it and you will immediately know a great deal about the Spring IoC container. This is also true in my case since most of my Spring knowledge is purely theoretical.

- Implement new features more easily: The Spring Framework is under extreme active development and new features get added often. It will be easier to implement/port these new features if the core is already based on Spring's core.

- Benefit from the Spring know-how: What I mean is that Spring has been out there for a couple of years and that it has proven to be a solid IoC container. The code that drives it has been tested by thousands of developers and many adjustments have been made to perfection it. Having an own implementation is like starting from scratch and it is much likely that somewhere down the road, we will make mistakes that have already been solved in Spring.

- Documentation: In open source projects, documentation is often brought down to a minimum which makes it very hard to attract developers and users. Spring already has numerous books and extended online documentation that can be used a reference and allows us to spend our (already limited) time on development.

- Making Prana a known IoC container: Being able to say that Prana is actually the Spring IoC container for Flex will most likely attract more developers because Spring is a name they trust. On the other hand, this is taking high aims, so we must make sure that Prana is actually as good as what Spring has to offer. Let this be an extra motivation to do a good job.

There are probably more reasons but these are the best ones I could think of. If you have any more you think are worth mentioning or if you are actually thinking about disadvantages, feel free to share them.

If you are interested in helping out or if you are curious to where this is evolving, there is a spring branch in the Prana repository. To get in touch, just drop me a note at info [at] herrodius.com or leave a comment here.

More Prana info: http://www.pranaframework.org

Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 
Previous Entries
WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Login