OK,
I have now created a proxy wrapper (DataLoaderProxy) and a mediator wrapper (AssetLoaderMediator) for the UnifiedLoader Class (changed the name to avoid conflicts with the flash.display.Loader Class);

so you have a choice to use a proxy, a mediator, or mash em up:~)

lol
very well put
thanks FYHO

hi chris....

made all your changes, and am working on a tutorial at the mo....

was wondering, I read a post here where you mentioned two ways of dealing with external assets...

data assets as proxies and display objects as mediators.

now, I've just lumped all types of assets as data, and wrapped the loader in a proxy, but, should there be a mediator implimentation of this for those purists who wish to keep their data and display assets separate... or is that over kill?

thanks, I really need some feedback from someone out side of my head space :~}
the command map is actually not part of the asset loader, but another util i'm working on. 
It allows chains of commands to be defined externally (in xml). I'm prototyping it at the mo, but its working far better than I thought it would. You are quite welcome to dig around if you like, but It probably wont make much sense without a test case.  I thought I'd take things a step at a time and get the assetloader done first.
cheers

well, I think its pretty much ready to go now for beta release
http://revisual.co.uk/?cat=58

Hi, I've been working on an assets loader, with the aim of it being a simple, stripped down framework that can easily be extended, and to be primarily used within the pureMVC framework (though it dosn't have to be)

Why do we need another "bulk loader"? Well, I think that the ones out there at the moment rely too heavily on Static data registries (no need in pureMVC, right), and have too much internal logic to "decide" what type of loader to use, and then to parse it. 

What I wanted was a loader that allowed me to treat all the many ways of loading data in the same way, yet to do so in the same way that the native classes would.

I mean that if I load an xml file, I want it to be loaded as a string, and allow me to parse it into an XML myself.

please take a look, its in an early stage at the mo, I'm happy with the architecture, but it needs proper testing. You can have a look here http://revisual.co.uk/?p=80.

In the spirit of the open source community I would like to offer this up to you guys as a pureMVC utility (if you like it), that I would be happy to develop and maintain. :~)

cheers

fleecie

ok, cool, I didn't realise I could contribute so easily.
Will get my project up to scratch first
:~)

Ok, I'm writing a set of utilities for pureMVC

and I wanted opinions regarding packages, and the best practice.

at the mo, my packages are name like this:

uk.co.revisual.puremvc

so all my code implemented using pureMVC is in this package. Is this acceptable, and easy to port to other peoples class libraries without too much confusion?

thought I'd share this asset loader util implimented in pureMVC that I've written.
not really ready for use yet, as its in early non tested phase, with some features still to be implimented.
at the mo its on my blog:

http://revisual.co.uk/?p=38

but I may transfer it to a googlecode page

would be interested in any comments

will the multicore version be in pureMVC 2?

I'll be interested to take a peak when it comes out

cool.

the appFacade parameter is a referance to the extended Facade (ie the sub class specific for each application). So when you initialise the extended facade, it passes a referance of its self up to the super constructor (the Facade). So it is this instance which is passed around the Frame work, not the abstract Facade. 

but now I see that maybe it isn't necessary, and that a simple 'this' would suffice.

Removing the singletons will theoretically allow many pureMVCed apps to exist side by side as there is no pollution of their Notification name namespace, as they all have there own MVC.

now I have only tested this an a single app, and it works fine.  It hasn't actually been tested with several apps running side by side (hence my use of the word theoretically)

not that I have anything against singletons, but I know a few people who just won't touch them.

So for their sakes, and as an intellectual exercise, I have removed them all.

practically speaking there is no difference for the user except two things.

you don't have to write a static singleton factory method on the extended facade, and in the extended facade's constructor, you need to send up a reference to itself in the super:

public function ApplicationFacade():void{
   super(this)
}

find source code here
www.revisual.co.uk/uploads/singletonlessPureMVC.zip

so you could expose a getView method... but maybe we're loosing something there.

there is a  call to the view singleton in the initializeController method that I missed... oh well