Open the Café Townsend sample.
(Be sure to check the source by right-clicking and choosing "View Source" from the context menu, click here to go to the source directly.)

Download the Flex/Flash Builder project and sources.

Discussion

In what follows, we will discuss the implementation details and motivate certain choices made in this design.

Package Structure

The first thing you might notice is the package structure, that might seem a bit odd at first since it is different from what most frameworks use or prescribe. This example follows the Layered Architecture, described by Eric Evans in the book Domain-Driven Design: Tackling Complexity in the Heart of Software (recommended reading). This architecture makes it easy to detect and apply the different layers of the application and forces us somewhat to have a clean separation of the responsibilities of each layer.

The layered architecture consists of four layers, as shown on the image below:

• Presentation Layer: contains the user interface (the view component and in this example the presentation models)
• Application Layer: coordinates the application and forms a communication channel between the UI and the domain
• Domain Layer: the core of the software. This layer defines the entities and repositories/services that form the business logic of the application. For the most part only the interfaces for the services will be written here. This layer does not contain any implementation details.
• Infrastructure Layer: provides implementation details for all other layers. Concrete implementations of services will be put here.

Note that it is certainly not needed to structure your application like this. Spring ActionScript does not impose or prescribe this structure, but we certainly think it is useful and wanted to introduce it in this example. Also note that while we have applied this architecture as packages in the same application, you might want to create different swc's or libraries for each of these layers so that they can easily be reused.

Presentation Layer & Presentation Models

This example uses the Presentation Model (PM) as the main presentation pattern for the UI layer. The PM allows us to extract all state and controller logic for the view into a separate class that is view agnostic. A view component contains a reference to its corresponding PM and delegates all UI actions to it. The view component can either instantiate the PM directly, or it can be given one, either by a parent component or by having it "injected" by the Spring ActionScript framework. The process of automatically injecting properties into a (view) component is known as "Autowiring" in Spring ActionScript. Note that since the PM is not a UI component and does not know anything about the view, it can be easily unit tested.

An example of autowiring can be found in the EmployeeLogin.mxml class:

The PMs used in this example will either delegate directly to the business logic (for instance for loading the employees) or will delegate to the Application Layer (for instance for logging the user out of the application). Here again, there is no strict rule to follow, but you can decide for your own what approach seems the bests.

Note that autowiring is disabled by default. This is because in bigger applications, there might be a significant performance hit when autowiring is used. It is adviced to finetune the autowiring by configuring the autowire processor to include or exclude certain classes. To enable autowiring, simply add the following to the XML configuration:

Application Layer

In some cases, the UI will delegate responsibilities to the Application Layer. Since the UI does not know about this layer, it needs a loosely coupled way of communicating with it. The communication channel that provides this capability in Spring ActionScript is the EventBus. It is implemented on top of Flash's event dispatching capability and forms a centralized medium for component and layer interaction.

In the example, the code behind the Logout button will dispatch an event via the EventBus. The application controller listens for this event and will handle it by invoking the logout method on the authentication service. Notice that the application controller takes the authentication service as a constructor argument and that the service is typed to the interface IAuthenticationService. The actual instance is provided in the (XML) configuration, were both the application controller and the authentication service and defined and linked to eachother.

Notice that the application controller does not explicitely listen for the logout event. Instead, it is sufficient to create a method and annotate it with the [EventHandler] metadata. Spring ActionScript will then introspect the controller, pick up all annotated methods and link them automatically with the event received from the EventBus.

Here's what the logout method looks like in the application controller:

Notice that the name of the logout method corresponds to the event being dispatched, namely "logout" (see the ApplicationEvents class for that). You can however also choose the name of this method as you like and specify the name of the event as an attribute of the EventHandler metadata.

As with autowiring, the processing of the EventHandler metadata is not enabled by default. If you want to use this in your application, simply add the following to the XML configuration:

For more information on the EventBus, please refer to the documentation.

Domain Layer

The domain for this application is extremely simple. All it contains is an Employee entity and an employee service in the form of the IEmployeeService. Except for the actual entities of the domain, this layer does not contain any implementation details for the services it provides, but merely defines the interfaces for those services.

Infrastructure Layer

The infrastructure layer is where the technical details of the applications live. This layer provides the actual implementation of the services found in the other layers. Depending on the different contexts the application needs to be able to run in, you might provide different implementations of the services here. The implementations used in the application can then be defined the a Spring ActionScript Application Context. As an example, think of an application that needs to be able to connect to a set of services using Remote Objects in one scenario and needs to connect to a set of Webservices in another scenario. If we provide both implementations, we can easily reconfigure the application by changing the XML configuration of the application context.

Application Context

Once we have all components, we can bundle them together and prepare them to be used in the application. By doing this, we are configuring the context of the application. In Spring ActionScript this is done by instantiating a FlexXMLApplicationContext (in case you are working with Flex).

The application context in this example is configured using XML, but it could just as easily be configured using an MXML configuration. Both approaches have there pros and cons and you should decide what fits best for you project.

Looking at the Main.mxml class, which is the entry point of the application, we can see that a FlexXMLApplicationContext is instantiated and given the path to the external XML file (application-context.xml) that forms the application context's configuration. Now all we need to do is wait for the context to load before starting the application.

Conclusion

This example contains significantly less code than the original Cairngorm version. This is mainly because Spring ActionScript does not impose any strict architectural rules and provides the developer with plenty of choice for architecting things that best fit the application being developed. What might work in application A might not necessarily work well for application B or C. Being given so much freedom and choice might feel awkward at first, but you will notice that this is actual a good thing and you will benefit greatly from it.

If you have any remarks on this post, please leave them in comments or contact me. Whether they are errors, things that are unclear, or general questions... all feedback is welcome.

General information and document about Spring ActionScript can be found at http://www.springactionscript.org/

Related articles:

• The Operation API
• Spring ActionScript 1.0 RC1 Released
• Spring ActionScript Devoxx slides

I'm pleased to announce that the first release candidate for Spring ActionScript 1.0 is now available.

Download | API Documentation | HTML Docs | Changelog

This release is considered feature complete and announces the final stage before moving to a final 1.0 release.

Amongst the many updates and fixes, these are the most important ones:
- Operation API (docs, blog)
- EventBus (docs)
- Task API (docs)
- MXML Configuration (docs)

These changes will be discussed in a couple of follow-up blogposts, so please check back soon for that. In the meantime, please refer to the documentation provided for more information.

I would like to thank all of you who have given us valuable feedback and provided interesting ideas, sent in patches, reported bugs or helped us out in whatever way possible. Your support has been priceless in the development of this framework and it would not be as rich as it is now without you.

Special thanks go out to Martino for mastering the Maven build system and fixing a lot of the problems that stopped us from releasing earlier, and to Roland who has written 99,9% of the AWESOME documentation and took a natural lead in the development of 1.0RC1. You guys rock!

Enjoy this release and have fun coding!

Spring ActionScript 1.0RC1 Changelog

• fixed constructor-arg type attribute was not declared in spring-actionscript-objects-1.0.xsd.
  

  config reference link

• added unregisterStageProcessor() method to the IStageProcessorRegistry interface.
  

  ASDoc link

• added DefaultFlexAutowireProcessor that handles binding using the [Autowired(name="objectName",property="property.chain")] metadata.
  

  documentation link

• added PureMVC documentation section.
  

  puremvc documentation link

• added autowiring support for injecting external property values using [Autowired(externalProperty="propertyName")].
  

  documentation link

• added parent context support to IObjectFactory interface and AbstractObjectFactory implementation.
  

  documentation link

• added skip-postprocessor and skip-metadata support for ObjectDefinition.
  

  skip-metadata link
  

  skip-postprocessor link

• added name and value attribute support to the property XML element, for defining external properties directly in the configuration instead of an external properties file.
  

  docs link

• added parent properties support to XMLObjectFactory.
  

  docs link

• added IStageProcessorRegistry interface and FlexStageProcessorRegistry implementation to support stage wiring in a multi-module situation (Thanks to Arnoud for helping debug this).
  

  docs link

• added extra functionality to the CairngormFrontController that enables to add commands that are being created by the application context (basically using the context as a commandFactory).
  

  cairngorm docs link

• renamed SASCairngormEvent to SASCairngormModuleEvent.
  

  cairngorm docs link

• ObjectUtils no longer has a dependency on the Flex framework.
• added core.* package containing the Operation API.
  

  operation docs link

• added core.event.* package containing the EventBus classes.
  

  eventbus docs link

• added EventHandlerMetaDataPostProcessor for automatic handling of EventBus events.
  

  eventbus docs link

• added parallel or sequencential execution to CompositeCommand class.
  

  operation docs link

• added core.task.* package.
  

  operation docs link

• added support for property chain retrieval in the FieldRetrievingObjectFactory, for example: Application.application.systemManager.stage can now be retrieved.
• added support for compound property names in XML config.
• added support for factory-object in AbstractObjectFactory..
  

  link

• added TaskNamespaceHandler for core.task.* package.
  

  link

• added createInstance(clazz:Class, constructorArguments:Array = null) method to the IObjectFactory interface to enable a factory to create objects with only annotations and have no object definition.
  

  link

• added operation and service for remoting via NetConnection.
  

  link

• added support for vector type in XML configuration..
  

  link

• Allow adding mx.flash.Event items to EventSequence and facilitate custom trigger calculation. (Thanks Jurgen).
• Added modulePolicy of type ModulePolicy to FlexStageProcessorRegistry that determines how modules will be handled.
• Minor documentation fixes. (Thanks Mark).
• added RouteEventsMetaDataPostProcessor to re-route events from arbitrary objects through the EventBus.
  

  link

• Added IApplicationDomainAware and ApplicationDomainAwarePostProcessor to automatically inject the context's application domain in objects that need a reference.
• Added MethodInvokingFactoryObject to be able to inject method results from other objects.
  

  link

• Added util:invoke element as a configuration shortcut for the MethodInvokingFactoryObject.
  

  link

• Added support for injecting the application context by using ref="this" in the configuration.
  

  link

• Added Maven mojo to generate a flex-config file from an application context (Thanks Ryan).
  

  link

If you have any specific questions you can post them in the comments or check our forum.

Enjoy.

Don't expect an updated version of the Cairngorm framework as you know it though. Cairngorm 3 is not aiming to be an MVC implementation, and thus moves away from what version 1 and 2 were, but now consists of a set of patterns and practices, together with a series of libraries that can help to solve common problems.

The Patterns & Practices Group at Microsoft have been promoting a similar mindset for quite some time actually: Prism - patterns & practices Composite Application Guidance for WPF

I can only encourage this decision as it is exactly how I personally think about application design and architecture, especially in Flex and AIR applications. This is also what we are trying to do with Spring ActionScript: our main goal is to provide a solid Inversion of Control container that supports multiple configuration options (XML, MXML, metadata driven component scanning, ...) and promote it as a foundation to build applications (and frameworks), with or without your favorite MVC framework. Although we are working on a set of base classes that provide infrastructure for your application (under the name MVCS) with Application Events, Controllers, Abstractions for service layers, ... by no means do we want to market the Spring ActionScript framework as yet another MVC implementation. (You might wonder why we are calling it MVCS then, and I'm actually wondering the same... I guess marketing and buzzwords in the opensource world are also important. All kidding aside, the name is certainly subject to change).

What's in a name

Since this is a complete change of direction for the Cairngorm framework (which it actually no longer is) I would have expected a new name. Continuing to use Cairngorm as a name is in my opinion a bad move and will cause major confusion amongst developers and other people involved in the development process. I think the best thing for Adobe, or at least their Technical Services department, would be to let go of the name and choose a new, fresh name that moves away from the past. (Besides that, who can pronounce "Cairngorm".)

Dependencies

I noticed that some of the modules that Cairngorm 3 provides depend on other libraries/frameworks, and in general the Parsley application framework. While Parsley is certainly a major player amongst the IoC/application frameworks, and I sincerely respect the author's work, I don't think this is a good decision. In case you are wondering: Yes, I would say the same thing if they decided to depend on Spring ActionScript.

The usage and choice of a concrete dependency will have consequences for the adoption and integration of the libraries that Cairngorm 3 provides. Think about it: Why would you want to pull in Parsley, perhaps only to use some of its Reflection API, if you are already running on Spring ActionScript or any other IoC container?

We, the Spring ActionScript team, have actually questioned ourselves about this in the past and have therefore decided to move all the common and reusable code from Spring ActionScript into a set of libraries known as the AS3Commons project. In that respect, I'm a bit disappointed that for instance the AS3Commons Reflect library is not used for reflection purposes, since I think it is more abstracted and unintrusive than a subset of an all-encompassing application framework. Perhaps this may be our fault of not promoting the libraries and the project enough. However, I certainly think that AS3Commons could be a wonderful project and would help to provide common libraries not only to Flex and AIR developers, but to ActionScript 3 developers in general, if it were embraced by the community.

Flex and MVC

Given that RIA technolgies are still evolving at a very fast pace, it is really remarkable to see the huge amount of MVC implementations appear. Not specifically aimed at Cairngorm (at least the previous versions), but rather at almost all MVC architectures available for Flex development, my personal feeling and experience is that the use of MVC architectures in the Adobe RIA space is almost a dogmatic thing and is not needed in most cases. The problem is that people just take an MVC framework as it is and implement it in their applications. More than often not questioning whether or not its usage is justified. Things that could easily and cleverly be solved are ripped apart across layers of the architecture, introducing levels of indirection that are in most cases not needed. The only thing they add is complexity and counter-intuitive development practices.

One of the main arguments for using an MVC framework is that the code is "easy to understand". Of course the code will be easy to understand if you have been developing with the framework of choice for the N-th time or if you have been digging into the code for a serious amount of time, but ask a newcomer to look at the code and try to explain to you what it is actually doing... I think you'll be surprised by the responses.

I'm not saying that the use of a particular MVC framework is de facto a bad thing, but the "religious" use and the blind adoption and implementation make a framework a killer for your application. I would encourage everyone to start their next project without an MVC framework and just use the Flex framework with a healthy knowledge of design and presentation patterns. And even if you are using an MVC implementation, think about each layer you introduce, why you need it and the pros and cons it brings.

Conclusion

It's good to see that Adobe is rethinking their approach to RIA architecture and development practices. I also hope that they will be more open to community input and feedback than they were in the past. Although they did several attempts at engaging the community, I don't think they really succeeded in that. If not open enough, people will just continue to fork the "framework" and provide extensions that will end up in alternative implementations anyway.

I'm looking forward to seeing how all of this evolves.

The Spring ActionScript project has a new home at http://www.springactionscript.org!

We have been updating the documentation extensively and although this is still a work in progress, this should be a valuable resource to get started with the framework. Please see the "Documentation" section for more info and available doc formats.

There are also some neat new features like advanced autowiring and support for custom XML namespaces (available in SVN) that will be distributed with the new 0.8 release, expected to be released by the end of this week.

As usual, we appreciate any feedback. Join our Google developers group or the forum.

Have fun coding!

I'm pleased to announce that the Spring ActionScript 0.7.1 release is now available.

Download | API Documentation | Changelog

This is a minor release that fixes 2 blocking issues:
- import nodes were not parsed correctly, which resulted in the imported nodes not being created.
- circular reference error when 2 objects have bidirectional references.

We also added some extra classes to the domain package.

Enjoy!

I'm pleased to announce that the Spring ActionScript 0.7 release is now available.

Download | API Documentation | Changelog

This is the first official release after switching from the Prana Framework to Spring ActionScript. Note that this release does not contain the Cairngorm and PureMVC extensions since these will later be released as separate extension libraries to the framework.

Some of the major changes and enhancements include:

Reflection API is now AS3Reflect

The reflection API is now provided as a separate project named AS3Reflect. This was a demand from several developers that wanted to use the reflection classes without having to use the whole Spring ActionScript codebase. For more info, please see http://code.google.com/p/as3reflect/

MVCS Support

Inspired by the MVCS principles that Joe Berkovitz describes, we created some experimental classes to support the MVCS workflow. Combining these principles with the IoC container of Spring ActionScript is actually very powerfull. Especially if you incorporate a presentation pattern like Presentation Model, you get maximum flexibility and simplicity by autowiring presentation models from the application context into the view layer of your application. I really recommend reading the MVCS and Presentation Model/Autowiring parts of a previous blog post I wrote about this.

IoC Container

We have improved many things in the IoC container and added support for new things like parent and dependant objects. We will continue to improve the core container as we work towards a 1.0 release and will add support for new tags and attributes based on community feedback. So be sure to get in touch with and give us your feedback.

If you feel like helping us out, we could certainly use your help. This project is entirely created on a volunteer basis and in our spare (and limited) free time so needless to say that the more people, the faster we can deliver new releases and guarantee the quality of the framework. So if you think you have someting to offer, be it as a developer, tester, documentation writer, sample creator, ... please contact me or leave something in the comments. All help is more than welcome.

Enjoy this release and have fun coding!

Since time was limited (or in case you were not there), I'll run through the key features of the code I ran through and try to give some more explanation.

Targeting BlazeDS via remoting and messaging

Whenever I'm hitting a backend, I try to have the endpoints externally configured. This allows me to switch between different endpoints - different test or production servers for instance - just by specifying the ip and port in an external properties file. This means that you don't have to specify any compiler arguments that point to the services-config.xml or messaging-config.xml files.

You can set up a channelset and a consumer with the following code. Notice the "method-invocation" element that allows you to execute a method on the object you create. This allows us to directly pass in a channel to the channelset. (In case you are interested, the method-invocation element is preprocessed to an instance of MethodInvokingFactoryObject)

Have you noticed the placeholders "${...}" for the host, port and context-root? These are loaded from a properties file that is referenced in the application context file.

Here's the external properties file:

And here's the import declaration in the application context xml file:

Of course, you can also specify remote objects in the application context. Here's an example:

Notice that we actually split this up into 2 objects. The first object is an abstract remote object which we use as a parent object for concrete remote objects. Notice the "abstract=true" and the "parent=remoteObject" properties on these objects.

MVCS support

As part of the project we are working on, we also starting working on some experimental MVCS support. If you haven't heard of MVCS, be sure to check out at Joe Berkovitz' blog.

What we provide so far are some interfaces and abstract base classes for services, operations and commands. Let's look at some code for services and operations.

Here's an interface for a user service, which defines a "getAll" method.

We now want to create a concrete service for that interface. For instance, this could be a remote object enabled service. For that, we have a abstract remote object service base class.

For testing purposes, we could also create a mock user service:

We can now define these objects in the application context as follows:

You can now use one of these implementations by calling the getAll() method. Make sure that you type the service to IUserService and not to a concrete implementation:

To implement your own services, you don't necessarely need to extend the AbstractService or AbstractRemoteObjectService class. These base classes just provide you with some convenient methods, like "getOperation" that creates a generic AsyncOperation for you.

You could of course also create an own implementation of the IAsyncOperation interface for your specific needs. For instance, you could create a GetAllUsersOperation that has all the logic for invoking a method on a remote object and that also deals with the result and fault handling of the remote call.

Presentation Model and Autowiring

I mentioned that we were using Presentation Model to seperate our UI state and logic from our views. This has worked surprisingly well for us and it certainly allows us to write better tests (for the presentation model). If you are new to Presentation Model and Presentation Patterns in general, I really recommend taking a look at the writings by Martin Fowler and Paul Williams.

Seperating logic and state from the view is one thing, but of course in order to use this combination you have to provide your view with an instance of a presentation model at some point. It's easy to read a presentation model from an application context, but injecting it is not that easy. Especially if your view component is nested a few levels deep inside other view components, it can be tricky to pass in the instance of the presentation model. We started of by passing in the presentation models from the root of the application through all components until we had finally reached the component that needed the presentation model. Needless to say that this approach required us to write a lot of extra code that really wasn't supposed to exist...

Enter custom metadata and SystemManager! Using the systemManager, you can listen to events that get fired when view components are added to the stage. This was exactly what we needed to know. Combined with a custom metadata element [Autowired], we now support dependencies being injected into views automatically.

Here's how it works. Suppose you have a UserPanel and a UserPanelPresentationModel. In you UserPanel you'll have a reference to that presentation model so you can actually use it in your view component. By adding the extra [Autowired] metadata you can mark a property (the presentation model) as a property that needs to be autowired when the view is created and added to the stage.

In your UserPanel.mxml file, you declare the presentation model as follows.

Now all we need to do is listen to the ADDED event on the systemManager and write some glue code that injects the presentation models defined in the application context into the view components. This code goes in your main application file.

You may have noticed that we do some extra checks on the attributes of the Autowired metadata. This is because the code above support autowiring by type (the default) and autowiring by name. Autowiring by type means that we will look in the context for objects that are of a certain type. If we find one, we will inject it. Autowiring by name means that we will look for objects in the context that have a certain id.

You can set up autowiring by name as follows:

Conclusion

I hope you now got a good understanding of some of the key features, best practices and what we are doing with Spring ActionScript in general. Don't hesitate to join our forum or the team if you want to help us out. We are really looking for more people to join, especially for working on samples and documentation.

http://forum.springframework.org/forumdisplay.php?f=60

I'm pleased to introduce a new Spring extension called Spring ActionScript. This extension, formerly known as the Prana Framework, is aimed at bringing Inversion of Control to ActionScript along with several other interesting utilities.

The extension is written in ActionScript 3 and is targeted at Flex, AIR and Flash developers. The IoC container and its XML dialect is heavily influenced by that of Spring so it should be easy for developers familiar with Spring to get started with it.

Spring ActionScript contains the following features:
* Inversion of Control container - XML driven, based on Spring
* Reflection API - providing a decent API around describeType()
* Cairngorm extensions - configurable Service Locator, extended Front Controller with command factories, Command chaining, ...
* PureMVC extensions - bringing Dependency Injection to PureMVC
* several utilities, assertions, etc

We are also working on the following features, all of which are in an experimental phase:
* MVCS support - providing an architectural framework based on Model-View-Controller-Service
* Domain Driven Design utilities - base classes for entities, value objects, enums, repositories and services
* SqlLite database templates
* Aspect Oriented Programming

The project is currently incubated as we work towards a 1.0 release. The latest available (Prana) release is 0.6 and we plan to release a 0.6.1 version in the coming weeks that introduces the switch to Spring ActionScript.

For more info, please see the following links:

* SVN - https://src.springframework.org/svn/se-springactionscript-as
* FishEye - https://fisheye.springframework.org/browse/se-springactionscript-as
* JIRA: http://jira.springframework.org/browse/SESPRINGACTIONSCRIPTAS
* Forum: http://forum.springframework.org/forumdisplay.php?f=60

Thanks to SpringSource and everyone involved in making this happen!

Hope you enjoy this extension!

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:

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.

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.

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.