Message from discussion
Major release: merging the li refactor branch
MIME-Version: 1.0
Message-ID: <bdc5d5a5-38ae-42d5-9cb1-4ceccd2b7869@d4g2000prg.googlegroups.com>
Date: Sat, 1 Mar 2008 14:44:46 -0800 (PST)
Received: by 10.150.185.14 with SMTP id i14mr411425ybf.7.1204411486965; Sat,
01 Mar 2008 14:44:46 -0800 (PST)
X-IP: 201.20.192.78
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US;
rv:1.9b3) Gecko/2008020511 Firefox/3.0b3,gzip(gfe),gzip(gfe)
Subject: Major release: merging the li refactor branch
From: Arthur Debert <deb...@gmail.com>
To: BulkLoader users <bulkloader-users@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
I`ve done a much needed refactor, and also implemented a reasonable
test suite for this change. The rationale for those changes are at:
http://www.stimuli.com.br/trane/2008/mar/01/bulkloader-refactor-me/
I am also calling this a release candidate. A few bug fixes releases
and we'll have a 'proper' 1.0 release.
============================================================================
Backwards incompatible changes from the li-refactor branch (rev 163
and up):
============================================================================
Types
=====
The whole mess of types is gone, now available types are video, sound,
image, movieclip, text, xml.
LoadingItem
===========
LoadingItem now is just a base class, that does most house keeping
work related to loading items. Each type has now a LoadingItem
subclass, that knows how to load that type in particular. This makes
it easier to to extend and understand BulkLoader, but most users
shouldn't be impacted by that at all.
Lazy Loaders
============
Lazy Loaders, BulkLoader instances that were created in external file,
such as xml files were very counter intuitive to use. User should
subclass them, attach events in the xml file (bad practice by the way)
and required a few hoops to use. The new LazyLoader design subclasses
BulkLoader, so all you have to do is to create the lazy loader you
need (xml or json) with the url where the external definition lives,
and that's it. You can attach group events to it as with any
BulkLoader instance. If you so desire, you can listen to an event just
as the external definition is loaded, and attach individual events to
each item at that time, just before all assets begin to load.
hasItemInBulkloader is Static
=============================
Makes much more sense this way.
traceStats name changed to getStats
===================================
Since traceStats wasn't tracing anything, it just made more sense to
rename it.
Allows more that one item with the same URL
===========================================
It turns out that there are several occasions where you need to have
more that one item with a common URL. So now, BulkLoader allows
repeated urls, the only constrain enforced is that each items id must
still be unique.
Public for all
==============
I know this one is controversial (I plan to explain my thoughts on
that one better soon), but almost all properties, either from
BulkLoader or LoadingItem are now private, even those intended for
internal usage only. Any thing (properties, functions) that is
intended for internal use only begin with an underscore ("_"). This
means that the only thing stopping people from using internal parts is
convention. If you are using function or property that starts with an
underscore, be warned: those are for internal usage, they may change
in future releases, and you must know what you are doing. The public
getters and setters were kept to allow safe access to things that are
safe to access.
============================================================================================
New Features:
============================================================================================
AutoID:
=======
Very often you use the filename for the id attribute, such as:
bulkLoader.add("somesite.www/config.xml", {"id":"config"});
BulkLoader can now add an automatic id, from the filename if:
- the "allowsAutoIDFromFileName" on BulkLoader is set.
- When adding, you don't explicitly set an id
Thanks Pedro Moraes (http:///www.pedromoraes.net) for the idea.
Variable Subsitution:
=====================
For many assets, you want to access from a common url base, such as a
domain name. You can now add variables inside urls to be resolved at
run time. Say most of your static assets live in myimage.com/images/
and most of your xml configs are dinamically generated from my-
source.com/api/, instead of having to type those over and over again
(and retype them if the domain name changes) you can define them in
variables to be expanded at run time. Example:
<pre>
var bl : BulkLoader = new BulkLoader("main");
bl.stringSubstitutions({
basic_path: "http://www.myimage.com/images/",
dinamic_server:"http://my-source.com/api/"
});
bl.add("{basic_path}backgound.jpg");// expands to http://myimage.com/images/backgound.jpg
bl.add("{dinamic_server}config.xml");// expands to http://my-source.com/api/config.xml;
bl.add("{ basic_path }logo.jpg");// expands to http://myimage.com/images/logo.jpg
-> spaces **inside** brackets are allowed
</pre>
Note that only letters, numbers and underscores are allowed as
expansion names, ("base-path" is not), in order not to clash with the
regexes used in the expansion.
Thanks Pedro Moraes (http:///www.pedromoraes.net) for the idea.
Reload:
========
You can now reload a dinamic response that might have gotten stale
since the last time you made the request. You can reload it with:
<BulkLoader>.reload(key : *)
Where key is the usual combination of id, url as a string or url.
This will force the item in reloaded to be loaded right away, with the
same caveats of loadNow. Also BulkLoader will delete all references to
the older item.
Thanks Pedro Moraes (http:///www.pedromoraes.net) for the idea.