Here are some important URLS for the project:

The project has historically been located here: http://trac.puremvc.org/PureMVC_AS2
It has been moved here: https://github.com/PureMVC/puremvc-as2-standard-framework/wiki

The Project Owner is:
Pedr Browne <pedr.browne@puremvc.org>


-=Cliff>

Here are some important URLS for the project:

The project has historically been located here: http://trac.puremvc.org/PureMVC_CSharp
It has been moved here: https://github.com/PureMVC/puremvc-csharp-standard-framework/wiki

The Project Owner is:
Andy Adamczak <andy.adamczak@puremvc.org>

-=Cliff>

Hi folks,

If you're seeing this group, it's because you've been added as a result of showing an interest in working on a port of the PureMVC framework. As you probably know the framework is based on design patterns that are abstract enough to be implemented in virtually any modern day object oriented programming language.

A number of relevant platforms have been targeted, but if you would like to discuss starting a port to one not mentioned here, please speak up!

Right now, the target platforms are:

AS2 - (completed except unit tests aren't ported, and need demos)
AS3 - (the original, stable, but could use demos and utilities)
ColdFusion - (port is underway and could use help)
C# (we have a potential project owner, but not started yet)
Java - (Underway. Will shortly have more status)
Perl - (project needs an owner)
PHP - (project needs an owner)
Python - (project needs an owner)
Ruby - (project needs an owner)

Each of these ports has its own members-only forum where the discussion for the port in question should take place. If you do not see the forum for the port you'd like to work on, please contact me. Each port has an SVN repository and a Trac source code/project management installation as well. Look to the individual forums for more information about these resources.

A web based repository browser that shows all PureMVC.org repositories is located at http://browse.puremvc.org/wsvn/

This forum is for the meta discussion of how a port should be managed, what constitutes acceptable documentation, what tools should be created for cross-port development etc.

Also, we're porting to both client side and server side languages. The original PureMVC framework was intended for writing the client side of an RIA. Part of the discussion that needs to take place in this forum is how well the patterns map to the server side.

We know that there are plenty of server side MVC implementations - Struts being the most prevalent in the Java world, for instance. We need to analyze not only how the patterns map to the server side, but also what the communication patterns between a PureMVC client and a PureMVC service might look like.

This is a pretty exciting next step for PureMVC.
-=Cliff>

This topic has been moved to Bug Report.

http://forums.puremvc.org/index.php?topic=112.0

With the currently documented idiom, to start up a PureMVC application built in Flex or AIR we:

1) Allow the MXML view to be built from the Application or WindowedApplication tag,
2) In a script block, we initialize a variable with the Singleton instance of the Facade, creating the Model, View and Controller
3) On the creationComplete event for the application, we create a Notification with a name like STARTUP,
4) Call the notifiyObservers method of the facade, passing the Notification and a reference to the Application itself
5) A StartupCommand is triggered which prepares first the Model and then the View.

This leaves you with a top level app looking similar to:

:


<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="horizontal"
    xmlns:view="com.me.myapp.*"
    creationComplete="initApp()" >

    <mx:Script>
        <![CDATA[
            import org.puremvc.patterns.observer.Notification;
            import com.me.myapp.ApplicationFacade;
           
            private var facade:ApplicationFacade = ApplicationFacade.getInstance();
            private function initApp():void
            {
                facade.notifyObservers( new Notification( ApplicationFacade.STARTUP, this ) );
            }           
        ]]>
    </mx:Script>
   
    <!-- Top level controls and containers of app go here-->

</mx:Application>


That places more knowledge of the PureMVC system than I'd like in the MXML Application, which is just a view component, really, and should be constrained by the same rule we apply to all view components, which is to make them portable by reducing their knowledge of the system they're attached to.

But we've got to get the party started somehow. Here's how to do it with way less knowledge of the PureMVC apparatus.

1) Add a public method called 'startup' to your concrete Facade which accepts a reference to the Application
2) In the script block of the Application, keep the initialized facade variable, but get rid of the 'initApp' method.
3) In the creationComplete handler of the Application tag, simply call 'facade.startup(this)'

This leaves you with this method in your ApplicationFacade:

:


public function startup( app:Object ):void
{
    notifyObservers( new Notification( STARTUP, app ) );
}           


And an MXML Application that looks like this:

:


<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="horizontal"
    xmlns:view="com.me.myapp.*"
    creationComplete="facade.startup(this)" >

    <mx:Script>
        <![CDATA[
            import com.me.myapp.ApplicationFacade;
            private var facade:ApplicationFacade = ApplicationFacade.getInstance();
        ]]>
    </mx:Script>
   
    <!-- Top level controls and containers of app go here-->

</mx:Application>


This method works just as well in Flash or FlashLite (yes, an AS2 port is working and coming soon) where we can just call it from the actions of frame 1 of the main movie. There it may this simple:

:


import com.me.myapp.ApplicationFacade;
ApplicationFacade.getInstance().startup( _root );


This works well for me and is definitely the recommended way to startup your application. I will be updating the Best Practices doc and the demos eventually, but there are a lot of irons in the fire right now, so I at least wanted to get this out there for folks getting started.

Of course this doesn't have any impact on your existing apps if you don't refactor them to use this idiom. It's just a cleaner way of doing things.

-=Cliff>

This topic has been moved to Bug Report.

http://forums.puremvc.org/index.php?topic=80.0

This topic has been moved to Bug Report.

http://forums.puremvc.org/index.php?topic=65.0

If you have a phone with broadband Internet access, and want to view these forums on the go, simply browse to http://forums.puremvc.org

The mobile browser should be detected and you'll get a really nice experience on handheld. Works great on my Blackberry 8830.

-=Cliff>

Hello All,

I'm currently working on a PureMVC Architecture 101 Course, and will soon be looking for interested participants in the process of testing and evaluating the overall courseware structure and effectiveness.

I've delivered extemporaneous multi-day training on Cairngorm, and I've been teaching Flex as an Adobe/Macromedia Certified Instructor since 1.5, and have had a lot of time to observe and think about courseware content, layout and delivery.

I've also felt that the thing that is missing after teaching a week of F2RCA ( http://www.adobe.com/support/training/instructor_led_curriculum/flex2_rca.html ) and F2DC ( http://www.adobe.com/support/training/instructor_led_curriculum/flex2_data_com.html ) or F2BDA ( http://www.adobe.com/support/training/instructor_led_curriculum/flex2_dashboard.html ) is Architecture.

Students come out of these classes, very well aquainted what Flex can do, and ready to build, but without a lot of direction in terms of architecture. I usually point people to the best design pattern books and sites that I know and offer to help with architecture if they need it.

But I think they'd be better served to have their top folks on the project sit through at least a 2 or 3 day structured architecture course in addition to the more development focused courses.

Recently while pondering next steps with PureMVC, I realized that courseware was the best way to proceed. I feel we need simpler examples, and a bunch of 'Hello World's are great for bitesized granularity, but won't really give you the big picture unless they fall within some ordered context.

Fortunately, Implementation Idioms had already layed out a logical way of unfolding the PureMVC design, but was entirely narrative.

With Architecture 101 the overall structure is similar, except there is much less narrative and much more hands on. Units cover the major actors in the applications you will write. There is some preamble to frame the Unit, but quickly it moves to the Labs, each of which has several learning points to be taken away and we set about absorbing them in the Steps for the Lab.

The courseware has a Lab project which you are modifying and a Solution project that you can refer to if you get stuck, though the Student Manual summarizes changes clearly and often.

If this sounds to you like a good way to learn PureMVC, and you'd like to get a first look at it when it is ready for testing, email me at cliff at puremvc dot org.

For businesses, FutureScale will also be offering PureMVC Architecture 101 as onsite instructor-led training in addition to the already available Adobe Flex training.

This is a brief post regarding recommended package structure for PureMVC-based applications.

First, if you look at the pacakage structure of the CodePeek application, you see:

com.futurescale.codepeek.*
com.futurescale.codepeek.model.*
com.futurescale.codepeek.view.*
com.futurescale.codepeek.controller.*

If you have a look at the package structure in the CafeTownsend demo, you see:

com.gurufaction.codepeek.*
com.futurescale.codepeek.business.*
com.futurescale.codepeek.controller.*
com.futurescale.codepeek.model.*
com.futurescale.codepeek.view.*
com.futurescale.codepeek.vo.*

The CafeTownsend demo was ported by Michael Ramirez and he did so with an eye toward Cairngorm developers and architects evaluating or migrating to PureMVC. So its package structure is influenced by Cairngorm. ARP has a similar format.

One thing I don't like so much about either package structure is that it makes you 'think' every time you look at it. It has crossed some visual threshold were we have to consider the 5 or so options, and consider what we're looking for and arrive at the conclusion as to which folder to open.

True, vo's may be shuttled around the three tiers and therefore logically stand 'outside' it also adds an extra package branch. The business delegate may do work for the controller or the model, and therefore would logically stand on its own island as well.

The reason I use the more simplistic 'model, view and controller', is that the original intent was to help separate code into three discrete 'piles'. This overcomes 90% of the problems we have with muddy responsibility placement in our apps. You still stand at the same crossroads, it only takes less time to pick a path.

So like everything, it's a compromise. More logical separations, which is good if there is an explosive number of classes that could be subdivided, or more minimal packaging, which is faster to traverse and means fewer regular occurrences of staring at your package structure wondering where something is, if only for seconds longer at a time.

From the project architect, PureMVC Implementation Idioms and Best Practices is 35 pages of essential architectural advice for implementing an RIA based on the PureMVC framework.

PureMVC.org -> Docs -> Best Practices