One more minor question/curiosity.

Is there a reason FlashApplication extends MovieClip rather than Sprite? MovieClip tends to carry a lot of extra code that isn't needed. Just curious. I can change my local copy to extend Sprite instead of MovieClip but was curious if there was a specific reasoning for it.

Jason,
However, If you intend to use Reflexive notification interests, you will need to extend FlashMediator/FlexMediator. Moving forward this is going to the key integration point for new Mediator specific features.

I'm using Pure AS3 for the moment so the Reflexive Notes aren't much use to me. But I'll keep in mind that future features will be added to the mediator and update my files accordingly. Thanks for the input.

There is no need for the JunctionMediator at all. The routing of pipe messages happens entirely underneath the system.

Sorry I may have mislead you with that statement. What I meant was the that we are replacing our old JunctionMediator with the Fabrication style mediator, but my other Mediators could remain the same (extending just Mediator) unless they needed the functionality of routing. Since my project is already well underway, I'm trying to add fabrication into my existing code and was just "speaking out load" about where I could avoid changing old code.

With the elimination of the ApplicationFacade, does one register all their commands in the StartupCommand now? So essentially the old ApplicationFacade has moved to the StartupCommand? I haven't tested yet, but I wonder how well the StartupManager utility will play with Fabrication. I think it should be fine.

Just trying to wrap my head around building large apps (many commands) using Flash with Fabrication. I assume only our old "JunctionMediator" mediator extends FlashMediator. The rest of our mediators still extend PMVC's Mediator unless we need the routing of Fabrication?

Just want to make sure I understand correctly.

Awesome news! Thanks, Darshan!

but you mean that you dont use binding ?

Sorry, I forget sometimes that the term "binding" means something in Flex, I'm an AS3 only guy. What I meant was that using Commands allows the View to access the Model without tying it directly to the Model. This allows you to change out the Model at anytime and reuse the View. But when you access the Model [Proxy] directly from the View [Mediator] that "binds" or "ties" the View to that particular Model.  Which is why I tend to use Commands and not access the Proxy in Mediators. I was only trying to illustrate one of the major roles a Commands has.

My point though was that you don't have to use Commands when dealing with Proxy-to-Proxy communications. You'd end up building tons of Commands just for your Model alone if you did, and this is unnecessary. Your Model should be walled off from your View, and vice-versa. But there's no need to add such separation between parts of your Model.

There's nothing wrong with Proxy's talking with other Proxy's, they are all part of the model and don't need to be partitioned from each other.

In my opinion, commands are best used in keeping the View from binding directly with the model (though some argue that using proxy's in Mediators is ok), and to handle domain logic as well as centralizing repetitive tasks used by multiple views.

Any chance we can get a peak at the updated source code while we wait for it to be set-up in SVN? This is something I could really use in my AS3 project but waiting till it's in SVN might be too long for my project.

Again, great work and thanks for sharing this.

I try to cover the difference in this thread. http://forums.puremvc.org/index.php?topic=457.msg3379#msg3379

There's no difference in using Pipes between Flex and Flash, the only difference is how you load modules since there is no Module class in as3. I gave a very simple example in the thread above on how to implement a module loader in as3. You might also look at the new Fabrication utility from Darshan  http://forums.puremvc.org/index.php?topic=681.0;topicseen since it covers the loading of modules AND applying pipes I believe.

There's also a new StateMachine Utility which us AS3 only guys might want to keep an eye on. http://forums.puremvc.org/index.php?topic=739.0

there's nothing on this link...
where is the as3 mvc multicore pipes sample?

http://trac.puremvc.org/Demo_AS3_MultiCore_Flex_PipeWorks

It's Flex and AS3, not as3 alone. They are more or less the same though. Very little difference in there use, only how you load modules.

Thanks for your reply.

What about sending the notification right from the event in the view?

Does this breaks the model a lot?

You shouldn't have PMVC code in your view components themselves, as this will bind your components to the particular app (by using the ApplicationFacade.NOTE_NAME). Best to have your mediator listen for the event, then have it dispatch the notification from there. This keeps your components oblivious to how those events are being used and thus making them reusable in other apps.

The first class is a ModuleLoader "Component" (like the Flex SWFLoader), which the proxy uses to load the swf modules and then discard them after they return. The next time a module is loaded a new ModuleLoader class (component) is created. It just allows me to use the same ModuleLoader Class in other projects/areas since it has no ties to PMVC, unlike the proxy which basically proxies the calls through to the ModuleLoader and is able to listen and respond using PMVC specific notifications.

As I mentioned earlier, the process of adding and using pipes is identical to the Flex examples once you have the swf modules loaded. Make a ModuleMediator and have it lay the pipes (or send a message to your shell to lay them, up to you) whenever a notification is received of a new module being loaded. You can see this process, minus the dynamic modules, in the PipeWorks demo.

NOTE: I only quickly cut out portions of my classes to give as a guide, they are missing other parts that weren't quite relevant to what I was trying to explain so I wouldn't use them directly

Oops, looks like I misread the question. I thought you wanted new instances of one mediator to handle each component. My bad.

I'm not sure I understand the question. What you have should work fine, passing the ItemId in the body of the notification, then the command using the body of the message and does it's thing.

If you mean how do you send the ID in the event, the simple answer is to create a custom event that has a variable containing the value.

Sounds to me like it is something that should be saved in your model if it's being used in multiple places. Use Cliff's example above to set the value on the model when it changes, then later have commands request the info from the model when they need to "read" it.

I guess it depends on the level of importance the value has. The above might be overkill and probably shouldn't be done if the value is purely a view related value, you have to be the judge on that. The other option is to expose a getter on the Mediator that then gets it from the component. I don't see anything wrong with that if you only need one or two values like this. But if you need to read in multiple values and reuse them, I'd argue you are better off creating a VO and storing it in your model somewhere and updating/getting values from that.

A third option is to add listeners to the component in the mediator, and have it update a public var. Then commands read the var on the mediator but there's no direct access the component (since it got its value from the change event).

:

public var sliderValue:Number;

public function onRegister():void {
     viewComponent.addEventListener(Event.Change, onChangeHandler, false, 0, true);

}

public function onChangeHandler(event:Event):void {
     sliderValue = event.target.slider.value //probably use a custom event containing the value rather than direct access
}