mloader released to haxelib

[David Peek]

Hello again!

Massive released another little library to haxelib today - mloader. This cross platform (flash9, js, neko, nme) library provides a simple API for loading different kinds of resources and uses signals to notify observers of progress, completion and failure. It also provides some useful utilities for queueing and caching loaded resources.

http://github.com/massiveinteractive/mloader

http://lib.haxe.org/p/mloader

We've been using the library on our projects for some time now, although as we made some substantial changes while getting it ready for release, we've marked this as a 0.9 beta release incase there's any feedback/changes to the API.

While the library is very useful, it's the basic concept that is the most powerful:

interface Loader<T>
{
    function load():Void;
    var loaded:EventSignal<Loader<T>, LoaderEvent<T>>;
    var content:T;
}

Which basically provides a nice construct for encapsulating the loading of any object. So, while the library defines an XmlLoader, which loads a url and parses it into an Xml document, the concept could extend to any value object in your application:

// for example some value object
class Data
{
    public var foo:String;
}

// which means these are interchangeable in your application
class JsonDataLoader implements Loader<Data> { ... }
class XmlDataLoader implements Loader<Data> { ... }

As long as the loaders conform to the interface, they can be used with the queue and cache utilities.

Another useful utility included with the library (although not well documented, I just realised) is a simple way for mocking Http requests when unit testing. It extends Http (and so is interchangeable) but fakes all responses:

var http = new HttpMock();
http.respondTo("test.txt").with(Data("Some content").afterDelay(10);
http.respondTo("another.xml").with(Error("#404 Not Found"));

You can see the source here: https://github.com/massiveinteractive/mloader/blob/master/src/lib/mloader/HttpMock.hx

We hope you find the library useful. Feedback, ideas and contributions are welcome as always.

Team Massive

[Nicolas Cannasse]

Le 09/08/2012 14:46, David Peek a �crit :

> Hello again!
>
> Massive released another little library to haxelib today - mloader.

Thank you for all these great libraries !

You should register mlotd.com "Massive Library of the Day" ;)

Best,
Nicolas

[Michael Cann]

lol :P Another great library from the massive guys nice work!

I just had a quick peek through the code and it looks like good stuff. One question however, is there logic for retrying on error?

On 9 August 2012 13:48, Nicolas Cannasse <ncan...@motion-twin.com> wrote:

Le 09/08/2012 14:46, David Peek a écrit :

Hello again!

Massive released another little library to haxelib today - mloader.

Thank you for all these great libraries !

You should register mlotd.com  "Massive Library of the Day" ;)

Best,
Nicolas

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

--
Mike Cann
http://www.mikecann.co.uk/

@mikeysee

[Franco Ponticelli]

Nice!

[David Peek]

Nope, but that's a great idea.

Will add it to the issues/feature requests page, unless you'd like to? ;)

[Michael Cann]

Sure ill add it :)

[David Peek]

I'm starting to worry we're spamming the list! I don't think we can keep it up though, we're working through a backlog of code we've been meaning to release for a while, but didn't have time because of projects. Anyway, it's a good chance to make sure the documentation and tests are up to date :)

We did start a open source projects page here: http://open.massiveinteractive.com but there's not much there yet.

Best,

David

On Thursday, August 9, 2012 10:48:52 PM UTC+10, Nicolas Cannasse wrote:

Le 09/08/2012 14:46, David Peek a �crit :

[Tynril]

This whole stuff is just AMAZING.

Can't wait for munit2 ;)

--

[Mihail Ivanchev]

I'm waiting for the 3-tier multi-platform, enterprise framework ala  http://www.sibvisions.com/jvx, you can start by releasing mbeans!

[j...@justinfront.net]

David

Initial questions...ideas and suggestions.

class LoaderQueue implements Loader<Array<Loader<Dynamic>>>

Does this need to be dynamic?  

In the past with loading I actually managed to allow users to choose between hxs hsl signal types, it would be nice if your able to abstract any dependancy on mSignal, I am not questioning it's use, it's probably great but probably not dissimilar from other common signal libraries used in haxe and if a user has a system they probably don't want to end up with several signal libraries, maybe it's not possible to do this but would be worth looking at to make your library more flexible, it's nice if your able not to tie developers into you whole workflow it means that they can for instance swap a signal class for a target yours may not have, or a feature you may not have, it's like not including tweening or physics engines in 3d libraries it give developers more flexibility.

In my loaders I normally use the swfloader to load images as well and sometimes have some wrappers so they can be used easily (deals with casting and wrapping) like so they can be used as buttons if needed ( sometimes have to draw a square over the image )... but also more importantly 

https://github.com/massiveinteractive/mloader/blob/master/src/lib/mloader/SwfLoader.hx

does not seem to provide the ability to change the application domain, for instance there is no structure for loading a third party swf, where you may also want to provide some default minimal communication... wire up some signals for start and finish and example implementation for the third party.

There is no CSV parser which can be useful, my main problem with CSV parser is defining the structure externally, but anyway maybe worth adding.

Very good your sharing this code, I would love a tutorial on the MVC you posted, I have not used pureMVC or similar ( beyond fixing others mess ) and have my reservations, prefering to hack my own custom structures with a nod to MVC but designed around the problem space, but probably ought to start using them.

Cheers

Justin

[j...@justinfront.net]

If I find time I may try cloning and trying out some of the features I mentioned.

I don't suppose you guys are releasing a XAML/MXML type component structure any time soon since I think that's what haxe's missing.

All the Best and thanks for sharing 

Justin

On 9 Aug 2012, at 15:02, David Peek wrote:

Oh, so this is how you reply to author :P

class LoaderQueue implements Loader<Array<Loader<Dynamic>>>

This is Dynamic because you can put any kind of loader into a queue, and as there is not LoaderQueue API for getting loaders it wouldn't really bring you any more type safety.

 

In the past with loading I actually managed to allow users to choose between hxs hsl signal types, it would be nice if your able to abstract any dependancy on mSignal

While I agree it's nice to let people choose, in this case the events are quite central to the library and rely on some msignal specific features. Neither library is very big, so worst case scenario someone needs to fork to replace one with the other.

 

does not seem to provide the ability to change the application domain, for instance there is no structure for loading a third party swf, where you may also want to provide some default minimal communication

The SwfLoader in the library is very minimal, and is used (by use at least) to simply load assets into the current domain for use as a library with getDefinitionByName. Very simple to extend and override methods to get more bespoke behaviour. I'm a big believer in YAGNI.

 

There is no CSV parser which can be useful, my main problem with CSV parser is defining the structure externally, but anyway maybe worth adding.

Again, not sure loading CSV is a terribly common use case.. but in this case easy enough to add without adding weight to everyones executables. Happy to take a contribution :)

Very good your sharing this code, I would love a tutorial on the MVC you posted

Checkout the example app, which demonstrates features (but ends up looking like a lot of work for very little functionality). As Dom said before, explaining MVC is always a double edge sword: you try to keep the example small, but as a result you end up with more boiler plate that application. It only really starts to make sense when you've been working on the same app for 3 months with 5 people and haven't gone insane from a lack of structure :)

Best,

David

[Cambiata]

Thank you, guys!
Looking forward to mplay2 (à la http://www.playframework.org/)! :-)

[Marcelo de Moraes Serpa]

Very interesting stuff!

- Marcelo

On Thursday, August 9, 2012 at 3:32 PM, Cambiata wrote:

Thank you, guys!
Looking forward to mplay2 (à la http://www.playframework.org/)! :-)