[Fling] Updated TypeResolver

[Grant Davies]

That makes sense but would you use the spring bean loading format for that, I don't think so, I think this is a layer on top of spring, maybe your transition manager is created by spring but I think the loading of those assets is a none spring xml file and tends to be applicaiton specific.  We could come up with a generic format for loading a set of assets based on an xml file but I don't think it would look like a spring config file, maybe I'm wrong I haven't done a great deal with spring yet.
 
Grant

________________________________

From: John Grden [mailto:neoriley at gmail.com]
Sent: Mon 5/22/2006 9:04 AM
To: Grant Davies
Cc: Chris Allen; Fling at osflash.org; Samuel Agesilas
Subject: Re: Updated TypeResolver


actually, I do this all the time with the blitz sites.  We have a config.xml file and the entire site is laid out (SWF's, FLV's, Bitmaps - all assets).  The heiarchy is completely spelled out by the config and is what the TransitionManager (the next peice in our puzzle) uses to manage the elegant loading/transitioning of parent/child SWF's. 

Example:

let's say you have this loaded:

home.news.archives

And you want to now load:

home.games.gallery.xbox 

TransitionManager will elegantly unload in order archives, then news then preload everything needed for games.gallery.xbox.  You can also tell it to preload assets FIRST , THEN transition everything out.

The xml also has information about bandwidth profiling and could even provide localization support: 

<asset type="movie" src="movies/home_%BANDWIDTH%" target="main.containers.home" />
<asset type="movie" src="movies/home_%LANGUAGE%" target="main.containers.home " />

So, since XML is really the universal layer, I say that's what we support - however that XML is derived, who cares, as long as it meets the spec.

Make sense?


On 5/22/06, Grant Davies <grant at bluetube.com> wrote: 

	I'm wondering how useful it is to load a bunch of assets from an xml file... I can see if if you were writing an image viewer or something but not sure about every day use.  I know in all my projects I want a group of assets loaded on demand not really pre-determined by xml, are you sure you're not trying to fit a round peg in a square hole ?
	 
	Grant
	 

________________________________

	
	From: Chris Allen [mailto:mrchrisallen at gmail.com]
	
	Sent: Sun 5/21/2006 11:32 AM
	To: Grant Davies
	Cc: Fling at osflash.org; John Grden; Samuel Agesilas
	Subject: Re: Updated TypeResolver
	
	
	

	On 5/19/06, Grant Davies <grant at bluetube.com> wrote:
	>
	> rock on dude, nice job, did you ever figure out that whole boolean isssue ?
	>
	Yep, I  sure did. Most of those problems were from using typeof
	instead of instanceof in the wrong places and the ordering of these.
	There was also the problem of me being a a dumb ass on occasion too.
	;-) The unit test proved to be very useful to verify that all of the
	types are being determined correctly.
	
	> Let me know what you need me to work on next..
	
	Well, I was thinking that it would be great to work on getting
	AssetLoader to load via a configuration file (xml for example). So,
	with this in mind, we can take the Spring approach and work on a
	simple IoC setup. We will need a good class loader, another class that
	reads the xml file and a basic ApplicationContext implementation. Luke
	had made a start to this a while ago, I will be glad to share with you
	his implementation. In fact I will just post it in SVN in another
	section so you can see it on Monday morning. I would prefer to keep
	the same syntax that Spring uses for these files. e.g. <beans><bean>
	etc...
	
	Other obvious things that need to be finished are the other Assets.
	John is working on the Video/FLV asset and perhaps he can whip up the
	LoadVars one as well. I will finish the AssetManager class on Monday.
	
	Let me know your thoughts on all of this.
	
	-Chris
	




-- 
John Grden - Blitz 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/fling_osflash.org/attachments/20060522/6b9d4628/attachment-0001.htm