BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Prana Framework Helps on ActionScript 3 Application Development

Prana Framework Helps on ActionScript 3 Application Development

This item in japanese

Bookmarks

Prana is an Inversion of Control (IoC) type of application framework for Adobe Flex or ActionScript 3 based development. InfoQ recently spoke with the Prana framework’s creators Christophe Herreman and Damir Murat to learn more insights about the usage of the framework.

InfoQ: Could you share with InfoQ readers a quick history of why you created Prana when there are other frameworks in place.

Herreman: Prana was born when we started rewriting an e-learning platform we had developed in ActionScript 2 and Flash. One of the libraries we were using, was the Inversion of Control (IoC) container that was available in the as2lib and since applying IoC had worked out very good for us in the past, we wanted to have the same functionality in our new platform. Since there was no ActionScript 3 IoC container available back then, I decided to create one myself.

I started with an own implementation, based on the Spring XML dialect and quickly decided to base the codebase as much as possible on that of Spring. That way, it would be easier to implement certain features since we could refer to the Spring sources; developers who are familiar with Spring would quickly be able to get started with Prana and of course it was interesting for myself to learn more about the Spring internals.

InfoQ: What do you think is the uniqueness of the Prana framework?

Herreman: It is a very generic, extendable and powerful IoC container. If you know the Spring IoC container, then you should have a pretty good idea of what Prana is capable of.

One of the nice extras for instance is that you can add custom preprocessors to the XML parser. A preprocessor is used to transform the XML once it is loaded and before it is parsed. You can then add new elements and attributes to describe your own objects in a way that is more convenient for you and have a custom preprocessor transform the elements to elements that the Prana parser understands.


Besides the IoC container, there is also a Reflection API that is built on top of describeType(). You then have an API for accessing runtime information of the objects running in your application, like what properties and methods they have, what interfaces they implement, etc. Next to that we are also working on some base classes for domain objects (inspired by the Domain-Driven Design book by Eric Evans). Those base classes have logic for comparing and cloning objects and a lot more. Prana also contains several interesting utility classes.

Murat: Prana also provides tools which can be used for quick starting Prana-based projects. One of the main features is dynamic updating of Flex compiler's configuration settings to include classes in compiled swf which are not reachable through code. In IoC systems this is very often since IoC encourage programming to interfaces instead to classes. Our tools are tightly integrated with Eclipse/Flex Builder, and they can, for example, detect when Prana's configuration changes and, when needed, they will parse Prana's configuration and update flex compiler's settings accordingly. This suppresses a need for classic flex "pattern" when programmers must explicitly declare classes not reachable in code (for example implementations of various interfaces) to include them in final compiled swf. Our tools take care of this automatically.

There are few more features like predefined project layout, prepared Ant targets, support for preparing a project for subversion sharing etc. All features are configurable and can be easily deployed simply by following step-by-step instructions. For more information interested developers can take a look at prana-tools project available in svn or in full distribution archive.

InfoQ: Prana integrates both Cairngorm and PureMVC. Could you explain why and how they these two framework play with Prana?

Herreman: We offer a set of extensions to both Cairngorm and PureMVC. Since we are using IoC, we also want to apply the principle to the framework we are using and be able to wire together the different parts of our application using Dependency Injection (DI).

For Cairngorm, we offer a service locator that can be configured in the IoC container. You can then define your remote objects, channelsets, consumers, etc externally and change them without the need to recompile your application. That way, you also don't need to compile against the services-config.xml file and it is easier to deploy to different locations. It also makes testing a lot easier. A typical use case is that you want to change endpoints when you move from your development machine to a testing server or production server. Prana makes this really easy without having to rebuild your application.

The frontcontroller we offer is a subclass of the Cairngorm frontcontroller and accepts custom command factories. That way, you have control over how commands are created and can inject extra properties into the commands once they are created. Besides that, we also offer support for chaining events/commands in a way that you don't need to explicitly invoke a command from another command.

Murat: Integration with PureMVC was initially created just as an experimental attempt to bring IoC in PureMVC applications. When it was obvious that this was possible, we decided to make that work public.

The main benefit for PureMVC users is a consequence of using the dependency injection pattern when dealing with dependencies. At the same time this is the biggest drawback too, since DI (dependency injection) usage inevitably changes some original PureMVC's usage idioms which are based on the service locator pattern. However, we believe that DI can be of great help in any application, and PureMVC apps are not an exception.
To ease the migration to DI, Prana's PureMVC integration was made to be as flexible as possible. For example, PureMVC programmers can choose a scale at which DI will be used. Prana can be used to manage only non PureMVC objects, or it can be used to manage only part of the PureMVC classes, and, of course, it can be used to manage all PureMVC and non PureMVC objects in an application.

InfoQ: What is the best way (or application type) you recommend to use Prana?

Herreman: If you need a certain level of flexibility in your application so that it can be ran in different contexts or you have a lot of configuration going on and want to have that centralized (and externalized), then I would highly recommend using Prana. Since it is based on Spring, many developers will already be familiar with the concepts and the XML dialect.

In our case, we had created an e-learning platform that people wanted to customize to their needs. Since we were hosting the platform ourselves, we needed to have a mechanism that allowed all these customizations. Without IoC, we would have to compile different versions of the software for every customization or we would have to write a custom configuration system based on XML or a database, which would have been an absolute maintenance nightmare. Instead we could have an application context for each customization and have that context loaded with the loading of the application, depending on the logged-in user. Even cooler was that we could generate application contexts on the fly from ASP pages that would read the settings from a database.

InfoQ: What's the long term plan for Prana?

Herreman: The most important thing is the IoC container and we want to get to a 1.0 release that guarantees a rock solid container. The container itself is pretty good so far, but we can still improve things and add more Spring features like parent beans and autowiring for instance. We also really need to get some documentation written.
We have also been talking with the development team about removing the extensions (Cairngorm, PureMVC, ...) from the main codebase and releasing them as separate extension libraries. This will have several advantages that mainly have to do with release management.

I also started working on an AOP (Aspect-Oriented Programming) framework but got stuck due to some ActionScript 3 limitations. The main idea behind AOP is that you create new typed object, based on a dynamic proxy mechanism, that implements a set of interfaces at runtime. The thing is that this is not possible in ActionScript 3. We have filed an issue in the Adobe JIRA and I would really appreciate it if people would vote and share there ideas on this. See the issue at http://bugs.adobe.com/jira/browse/ASC-3136

For the rest, we don't really have a strict roadmap. We introduce new features and improvements as we get new ideas and insights and we are always open for suggestions from other developers. We are also always interested in hearing from other developers that would want to join the team.

Rate this Article

Adoption
Style

BT