I was wondering what you thought of this post about organizing notifications:

http://labs.almerblank.com/2009/11/organizing-puremvc-notifications/

I like the idea of a Notifications Class, typed to INotifications that implements:

function register():void;
function remove():void;

But the last suggestion in this post is also interesting, by aggregating notifications specific to areas of an application in an all encompassing Notifications Class, which could be accessed through the facade.  However, I'm not certain about breaking from the best practice of using public static constants in the concrete Notification Class (LoginNotifications) and instead using only public constants.

Please see the above post...

Could you advise on best practice here?  Thanks!

Given that pretty much all actors in PureMVC have access to the facade, isn't this much simpler?

:

facade.registerMediator(new IndexMediator(indexView);

I mean, you need access to both the view and mediator to instantiate your VO, so why not just skip that biz and register the mediator directly with the facade?

Thanks,

I do understand the value of a "typed" VO, but in the case of loading XML, I was thinking of being lazy and using getters in the Proxy to return appropriate data from the structure of the XML object.  I could 'type' the data on the way out the door too, like:

public function get allProducts(productType:String):Vector.<ProductVO>
{
// TODO code:
// 1. do some e4x to get XMLList of products of productType
// 2. create Vector.<ProductVO>
// 3. loop products in XMLList
// 4. create ProductVO per iteration and push ProductVO into Vector
// 5. return Vector - OR return null if no records found, etc.
}

I really like your SmartVO example, and I guess what I'm suggesting is sort of what happening in your example, except that I'm suggesting creating the API for the XML directly on the Proxy.  But I suppose it's best to pass a VO in a notification instead of having Views directly access the API of a Proxy...

I guess my deal is that at this area of the application, in the Proxy, whether you offload your XML into a typed VO or use getters as above, it's the only place in the application that needs to know you're dealing with XML and with the particular XML structure.  I suppose if the XML changed, however, you're application could silently fail, or you'd receive null in return, prompting you to go hunting to see if the XML was properly formatted.  But wouldn't that happen anyway if you're building VOs?  As you mentioned, only schema could assist you here, no?

Thanks!

Thanks!

For anyone interested, there's a cool AS3 Class that generates a relatively certain unique ID, which can come in handy with the above approach of generating Core keys at runtime. The Flex framework has the UIDUtil Class natively, but for pure AS3, there's no such thing.  Check it out here:


http://www.rgbeffects.com/blog/development/actionscript-3-guid-generating-unique-ids-for-users-in-as3/

Ok, I've been asking questions, and I've been getting great answers, thanks so much for your time, Mr. Cliff!

Here's one about Proxies: In the case of using a Proxy to load XML, given that AS3 has pretty powerful XML capabilities with E4X, I often like to keep incoming XML data within an XML or XMLList object.  However, in PureMVC, because Proxies are suppose to steward a data object or VO, usually I see people shuttling their XML data into the VO.  But sometimes I'd kind of rather not do this...but instead just hold the loaded XML in an E4X friendly object.  Does that mean I can't be in the PureMVC club anymore?

But seriously, given that the Proxy is expecting a VO or data object, how should I proceed here?

Could I just do this within the constructor of the concrete Proxy:

:

public function MyProxy()
{
super(NAME, new XML());

// other concrete stuff
}

...and something like this in the onComplete handler of the URLLoader (PLEASE NOTE: the implicit getter for xml, which cast the inherited member, data, as an XML object ):

:

private function onComplete(e:Event):void
{
xml = new XML(e.target.data);
xml.ignoreWhitespace = true;
sendNotification(LOAD_COMPLETE, xml)
}

public function get xml():XML
{
return data as XML;
}

Would this be cool for handling XML?

Thanks!

Great stuff, again, thanks for your time, I'm getting it!

One more question:

Only have Mediators that actually expect to add components to their children listen of course...

Would it not be cool to create an AbstractMediator to listen for any and all ADD_TO_STAGE notifications, and allow concrete subclassed Mediators to respond if necessary?  Or would this get too expensive?

Thanks!

Wow, many thanks for your time, I greatly appreciate it!

Points 1 through 5 really clarified for me how to proceed in a production environment!  Thanks so much (and I might as well end this sentence with an exclamation mark, too)!

Another question (sorry, I'll have many, really sorry...):

What about privatizing the key, or using a unique ID, for each core?  I've read a bit about this on some posts, like here:

http://www.as3dp.com/2009/07/22/a-non-flex-actionscript-example-of-a-puremvc-multicore-application/#comment-3018

Would you be able to expand on this practice?

Thanks again!

sd

I've been studying hard on best practices, run through tutorials, searched and read posts, and there's still some general Multicore structural stuff not clear to me, so please forgive me if I ask a pile of basic questions here, many of which maybe well known to the community.

1. Cores: Shell (or other common names like Application, Main, Index) vs Modules?  Is the Shell's primary deal to load modules?  If so, where does this happen?  The 'getting started' tutorials I've read show the modules being created in a variety of Classes: in the Shell's Document Class, another in the ShellMediator - what is best practice here?  Does it matter where they are loaded?  Is there a utility for managing this?

2. Using/loading actual Modules:  Again, most of the getting started tutorials house the Shell and all Modules in sub-packages of the same application, ie: src.com.myapp.shell, src.com.myapp.moduleA, etc, but is this actually modular beyond packaging? 

In building non-Flex AS3 applications, I prefer to create modular sections of the application that can run on their own, this way I don't have to compile and wade through an entire application to test each Module.  I'm sure this is standard for most developers, however, in PureMVC, how would this handled exactly?  Should I load into the Shell (when I find out where it is best to do so) an swf file (a Module) typed to an Interface?


I'm sure I'll have many more questions, thanks very much!

Or it could be heard by the Mediator for another view component that has already been added to the Stage, who adds the new component as a child of its own view component. You can create your entire view hierarchy this way and not have to have the StageMediator manage every single placement and not have multiple classes manipulating the Stage.

Mr. Cliff,

So, with this second method you outlined, could I then:

1. create a generic ADD_TO_STAGE notification, and shuttle within its body a newly instantiated view.
2. allow each Mediator to generally listen for the ADD_TO_STAGE notification
3. allow each Mediator handle the notification by checking if the view contained in the body of the notification is of interest to the concrete Mediator
4. If yes, and add the new view to the Mediator's view component or subviews as required - the particulars here could be specified within the handle notification method of the concrete Mediator.
5. If no, do nothing?

Could this be a decent implementation of added views to the stage?  Or would I be causing the applications view structure/hierarchy to lean too heavily on Mediators.  Put another way, this mode of view instantiation pairs the display hierarchy of the application directly to the PureMVC framework.  I'm not sure that is the best approach.

OR, should the view be passed to a StageMediator, paired with a parent view and some parameters for placement and z-index?  Still here, I'm pairing PureMVC to the adding of views to the display list...

Again, thanks for your time, and kind regards.

On this same topic, if views should be instantiated within their Mediator, then is the viewComponent passed to the constructor of a Mediator always merely a reference to the stage or document class or the parent-view to which the view of the Mediator will be added?

Thanks!