Christophe Herreman

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

I’m proud to announce that Prana 0.4 has been released.

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

Nightly builds of Prana are now available at http://prana.herrodius.com. These builds are repository snapshots taken at 11 pm each day and come in 2 versions. One is the compiled framework in the prana.swc file and the asdoc api documentation. The other contains everything of the previous plus the sources and the samples.

Please note that these builds are for testing purposes only. Although they are released only after all unit tests completed successfully, things could go wrong. Use them to see if a bug has been fixed or if you can’t wait for the next official release before using new features.

There seems to be a problem with the Prana mailinglist hosted by sourceforge. I sent a couple of messages in the past week, but none of them seem to have gotten through. I hope this issue will be resolved soon.

In the meantime, if you would like to get in touch or have any questions about Prana then please e-mail me at info [at] herrodius [dot] com.

[Update] It seems that there is no problem with sending messages to the list, but that there is a problem with the message listing on http://sourceforge.net/mailarchive/forum.php?forum_name=prana-user

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