I wish there was. It is extremely hard to pull off in spare time. I get about one full day for it every two weeks. At least when its done I'll be able to refer to it as 'the eagerly awaited courseware'

-=Cliff>

The beta was by far the best single source for PMVC development I have read to date (outside of source code, but it would have been hard to get through that without the courseware)

You need to work on cloning yourself dude.

In all of my projects (fancy Flex or otherwise ;P ) I use an AbstractMediator, AbstractController, and AbstractProxy as a base for their corresponding concrete classes. In my abstract mediator, if I wanted all of my concrete application specific mediators to listen for a notification, I would override the listNotificationInterests and handleNotification methods. Then, in my concrete mediators, I will override them again, but make sure to use super.listNotificationInterests() in the methods. You may have to use super.listNotificationInterests.concat([ MyInterests ] ), but the switch statement in the handleNotification should work without any special treatment outside of the super call.

I generally do this in my concrete classes with onRegister() because I use the ApplicationSkeleton utility and all of my proxies and mediators want access to configProxy and localeProxy. The same principle should apply to your situation.

I create these, but they aren't INotification objects, they are called MyNotification (as an example) so that my commands can look for a typed body and act accordingly.

There is probably a good way to do what you are asking, but I haven't spent enough time with learning how notifications get pushed about to solve it. the sendNotification() method sends a stock notification object, so that is why I use the simple method above. Hopefully Cliff will enlighten us both.

I couldn't stand the smell, so I put my update apparatus in individual proxies for the VOs. I decided that I didn't want the view updating my model at all, and figured that it would create dirty objects. So now, to update an object it has to be saved to the database, which triggers the round of notifications that the object has been updated. Obviously you could still update the properties from anywhere (I really need to get/setterize them all), but I think I can take that out too and have my proxies fully marshaling the ValueObjects.

Smells like peaches instead of poo.

I've put an update method on my ValueObjects in my current project. It takes an object of the same type as an argument, checks against the UID, and replaces all of the other values if the UID is a match. It seems really handy when I am updating objects from forms and whatnot, but I wam wondering, is this just bad form? It makes me feel a little dirty

Cliff will usually tell people to use the path with less code, unless you need to make the call in other places also. There is nothing wrong with proxies calling other proxies. I find it absolutely essential myself.

The restriction is that you don't want you flex view components calling your proxies. I break this rul in one place, with the AppSkeleton's ConfigProxy and LocaleProxy because it makes for really clean localization and injection of variables from my config.xml.

Cheers.

So just to answer my own question, I implemented an AbstractApplicationFacade which my main ApplicationFacade then extends. I had been messing around with Fabrication, and it was shielding me from the facade and made it harder to go this direction. It would work great if I was going to go for a fully modular approach, but I want to use the shared library for my core applications (while leaving it open for future modules).

Thanks for the edification Cliff, as always. The Async messeging would drag me down, and the level of seperation would probably just hold me back at this point.

The way it is currently set up I only have to change the ViewPrepCommand in my core model for the specific application. I am trying to figure out how to not need to change the core at all, but I need to have at least one hook. In this case it is my ApplicationMediator that listens for the CORE_LOADED notification and initializes the specific application.

Would you have any thoughts on how I might notify my application specific structure after the core is loaded without altering the core classes? I'm stumped.

I am building a toolset that consists of a web frontend and a management utility for the owner to update the web front end and do various tasks. The web bit is Flex and the admin tool is an AIR application. Obviously they share a common data model, and this is the exact use I believe PureMVC is built for.

Right now I am 'planning' on using the core bits as a shared library, but I am wondering if this would be a good place to use a module. I don't know how to really go about it though, the application shell loads the core module, and then loads the appropriate view module? Would I have a base view module that first loads the core and then initiates itself after it receives a particular notification? Or is it better to just keep a library project and use the shared SWC?

I suppose it is all the same thing when it gets down to it, eh?

I do this like so:

:

public class MyProxy extends Proxy implements IProxy
{
        public static const NAME:String = "MyProxyName";
        private var instanceUID:String;

        public function MyProxy(instanceUID:String)
        {
                this.instanceUID = instanceUID;
                super(this.getProxyName(), new myVO())
        }

        override public function getProxyName():String
        {
                return NAME + "::" +this.instanceUID;
        }               
}
This way my proxy objects have a nice uniform prefix and their UID. It also eliminates the need to abstract the pureMVC paradigm of getProxyName(). Same concept, really, just a little less abstraction.

Awesome, thanks Darshan.

I have a question. I have several Air applications that I'd like to Fabricate. Should I just make a new class called FabricationWindowedApplication that mirrors the code in FabricationApplication but extends WindowedApplication instead? Do you think there is a better way to do this? I hate to repeat all the code, but I can't see another way.

Wow. This is a really cool utility. I love the router/firewall metaphor. The undoable command structure is interesting also, and I would love to see simple examples of this stuff in action.

I want to thank Cliff Hall for creating PureMVC. It has made my Flex programming much more fun.

QFE

I am quite new to all this, and having read the post I was like to enquire in terms of development whether it be flash website or RIA would it be better to learn and apply the standard version of PureMVC or the MUlti core version.

As Cliff stated, there is really no reason NOT to use multi-core, as even in an app that will 'never' need additional cores, it doesn't really change anything outside of when you have access to the facade in your actors (which isn't a problem, just a timing issue)

Also, I've updated this application quite a bit. I'm rather pleased with how the Wall Designer portion is shaping up.

All of my VOs extend EventDispatcher and I make liberal use of databinding. This is because the chances of me porting anything to Silverlight are null (famous last words?). ^^

It sounds like your life just got that much easier.

I define an AbstractProxy, AbstractCommand, and AbstractMediator (thanks Daniele). These three all have the common global proxies, LocaleProxy and ConfigProxy as well as my app specific core proxy objects. They also carry the utility methods for logging. After the initial load, all of my proxies/mediators/commands simply extend their abstract class and they are kept nice and clean.