I'm pleased to announce that the Prana Framework 0.5 release is now available.
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:
-
<objects xmlns="http://www.pranaframework.org/objects"
-
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-
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.
-
// load a single 'applicationContext.xml' config
-
var applicationContext:XMLApplicationContext = new XMLApplicationContext("applicationContext.xml");
-
applicationContext.addEventListener(Event.COMPLETE, onApplicationContextComplete);
-
applicationContext.load();
-
-
// load multiple config files
-
var applicationContext:XMLApplicationContext = new XMLApplicationContext(["applicationContext-1.xml", "applicationContext-2.xml"]);
-
applicationContext.addEventListener(Event.COMPLETE, onApplicationContextComplete);
-
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.
-
// in a file called strings.properties
-
s1=First string
-
s2=Second string
-
-
// in the config file
-
<objects>
-
-
<property file="strings.properties" />
-
-
<object id="string1" class="String">
-
<constructor-arg value="${s1}"/>
-
</object>
-
-
<object id="string2" class="String">
-
<constructor-arg value="${s2}"/>
-
</object>
-
-
</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
Christophe Herreman is a software developer living in Belgium. He's working on Flex based e-learning solutions at 
Subscribe to this feed
April 22nd, 2008 at 6:21 am
Hey Christophe … I wanted to thank you for your library its great so far
I went ahead and got one of your examples working with Flash Develop and posted here: http://tmp.nuiman.com/prana_v0.5.zip if anyone needs…
May 5th, 2008 at 12:33 am
Looks interesting!
Will this work with Cairngorm if using Universal Mind Extensions?
P.S. in prana-projects-0.5.zip prana-tools\resources\targetfolder there are real long paths that are too long for windows
Thanks, Steve
May 5th, 2008 at 8:09 am
Hi Steve,
I haven’t checked out the UM extensions yet but I’ll definitely put that on my todo list.
regards,
Christophe
June 19th, 2008 at 10:54 am
Hi Christophe,
I’ve been trying to use Prana to make our app modular or rather make Cairngorm modular which means that each module can add to the service locator and create its own controller. Because in my case it makes more sense to load embedded XMLs I implemeneted my own XML factory which just takes an XML object. On top of sits custom ApplicationContext which is just a wrapper around the factory. The factory mimics what the original XMLObjectFactory does (no XML merging, no imports though) by calling the XMLObjectDefinitionParser. With the orignal and my own implementations I tried two approches when each module adds to a single ApplicationContext instance or creates new ones. Some differences in behaviour in the latter case broght two questions I wanted to ask you:
1. Should the load/loadConfigLocation method be called only once in a factory/application context life time?
2. I found that the custom implmentations does not have issues with naming conflicts although in debug mode I can see that all of the objects defined in both files are there. It is not the case with the XMLApplicationContext and the underlying XML object factory. When lets say both configs contain a serviceLocator named the same the singleton won’t have services added later on. A similar thing happens with the CairngormFrontController - if the parameter holding commands’ package name is called the same it fails since the first value is applied to the instance created later on. Just wondering if it is an intended behaviour and if lack of those errors with the custom implementation is a side effect of some kind…
Cheers,
Bartek
June 22nd, 2008 at 7:55 pm
Hi Bartek,
if you haven`t done so, please check the Prana forum. There is a post about using embedded xml within the container and Erik recently added support for this. See the post at http://prana.herrodius.com/viewtopic.php?f=3&t=19
To answer your questions:
1. I haven`t done that before but I think it should be perfectly `legal` to do so.
2. There hasn`t been any design to handle naming conflicts right now. The last object will always win I suppose. I`ll try to check how spring handles this.