Christophe Herreman

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