Unified Assets loader

[Neil Manuell]

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

[puremvc]

Hi Fleecie,

Checked out your demo post. This utility looks pretty cool, and would certainly be a welcome addition to the PureMVC Project. Send me an email via the contact page, and we'll work together to get a project setup in the Manifold!

-=Cliff>

[Neil Manuell]

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

[puremvc]

I had a brief look at the code with respect to repository readyness and had a few first thoughts:

  * The package space shouldn't have camelcase in it. i.e. org.puremvc.as3.utility.assetLoader.* should be org.puremvc.as3.utility.assetloader.*.

  * In addition to camelcase, the commandMap classes fall as a sibling to the utility's package rather than within it. org.puremvc.as3.utility.commandMap.* should be org.puremvc.as3.utility.assetloader.commandmap.*. (Though I'm not clear on why they're separated to begin with, as I haven't dug that far in).

  * I'd suggest doing an 'organize imports'. (ctrl-shift-O) on each class to remove unneeded imports. For instance in:

ChainNoteNames

:

package org.puremvc.as3.utilities.commandMap.etypes
{
        import org.puremvc.as3.utilities.commandMap.patterns.observer.ChainNotification;
       
        public class ChainNoteNames
        {
                public static const POPUP_ALERT:String = "popupChainAlert";
                public static const INVOKE_COMMAND_CHAIN:String= "invokeCommandChain";
               

        }
}
  * Consistency of naming on the use of "que"/"queue". Most everywhere, in command names and methods, queue is being used, but in a few places, like LoaderProxy, it is used both ways: "queSortFunction" and "queueLength".


I like the deconstructors.
-=Cliff>

[Neil Manuell]

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

[Neil Manuell]

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?

[puremvc]

Personally I like for asset loading to happen in the view. IMHO, it makes the best separation of View and Model tiers.

However I empathize with the 'put all the loading of stuff in one place' line of thought as well.

It is therfore a decision I'd choose to leave up to the implementer.

If you make the choice for them by providing only one way to do it, then only the people who like the way you've chosen will use it happily. The rest will grumble or not use it at all.   

-=Cliff>

[Neil Manuell]

lol
very well put
thanks FYHO

[Neil Manuell]

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:~)

[Neil Manuell]

and the first of my tutorials are here

http://revisual.co.uk/?page_id=189

[Helmut Granda]

Has this project been abandoned?

[puremvc]

It's on the list to evaluate for inclusion in the repo, but there are several asset loading solutions vying for favor in addition to the one that is built into StartupManager. So rather than jamming every one into the PureMVC.org repo, and thus confuse everyone about which to use, it is still gestating. Check out the project, see what you think and report back. What do you like or dislike about it. This will help immensely.

-=Cliff>