A unified namespace and a dynamic library loader would be nice

[GoogleCodeExporter]

It might be worthwhile to implement an open source version of the loader API 
for our project.  Now 
there are about seven different libraries included in this project, so adding 
in some versioning a la 
the official Maps API might also be worthwhile.  This might also make 
integrating with the other 
Google JavaScript APIs easier. (See Issue 24)

An adaptation of the MarkerManager weather demo is attached using such a 
theoretical loader and 
namespace in combination with the Google loader.

Finally, backwards compatibility is important, as we've encouraged folks to 
link directly to the svn 
trunk.  Initially, a loader could essentially do the same, but implementing a 
versioning scheme 
and/or encouraging folks to link to /tags/ or something similar seems like a 
better idea.

Original issue reported on code.google.com by lem...@gmail.com on 26 May 2008 at 4:30

Attachments:

• gmaps-utility-library-loader.html

[GoogleCodeExporter]

Yeah, this is going to become an issue more and more. So, some things to 
consider:
- What if I want to load multiple libraries and have the same callback for all 
of
them? e.g. gmapsUtilityLibrary.load('markermanager', 'labeledmarker');
- What if I want to load a particular version of a library (not the release)?

Original comment by pamela.fox on 26 May 2008 at 5:32

[GoogleCodeExporter]

Made loader branch in r618.

Original comment by lem...@gmail.com on 26 May 2008 at 7:33

• Changed state: Started

[GoogleCodeExporter]

Hmm.. Have you seen this?
http://ajaxian.com/archives/announcing-ajax-libraries-api-speed-up-your-ajax-app
s-with-googles-infrastructure

(Admittedly, I didn't know about this project)

If this seems like it'd work well with what you're doing, let me know and I'll 
chat
with the team.

Original comment by pamela.fox on 27 May 2008 at 6:36

[GoogleCodeExporter]

Wow.  I hadn't seen that.  Now that they've more or less documented 
google.loader.rpl, this will take 5 minutes 
to get working.

Original comment by lem...@gmail.com on 27 May 2008 at 8:52

[GoogleCodeExporter]

One thing would be nice: in r620 I had to define the locations of our libraries 
using "../../../libname/version/".  
This is because the loader automatically appends /lib/ to 
google.loader.GoogleApisBase. It would be nice if that 
were not hard coded.  Also, r620 won't take advantage of the caching and server 
setup things that the other 
libraries (prototype, scriptaculous, etc.) will.  That would require something 
which I presume is in the future for 
the loader API.

Original comment by lem...@gmail.com on 27 May 2008 at 10:17

[GoogleCodeExporter]

Heya - I'm chatting with the AJAX libraries team now. Your code is great, but 
the
main thing its missing is the ability to specify a callback
(google.load("markermanager, "1.2", {callback:loadMap}) - and the only way we 
can do
that is with server-side support. So I'm hoping that we can become one of those
hosted libraries. I'll update you when I find out more.

Original comment by pamela.fox on 4 Jun 2008 at 5:02

[GoogleCodeExporter]

Per-library callbacks don't necessarily require server-side support.  They just 
need libraries that are aware 
that they are being loaded.  In r619 I had an implementation of such a system.  
.load(library, {callback:func}) 
can store the callback, to be called by the library upon loading e.g. 
loader.callbacks.libname.  The use of a 
well defined namespace (e.g. google.loader) can allow for a standard mechanism 
for executing custom 
callbacks without requiring the server to write any custom callback wrapper 
code.  External libraries loaded 
through the google.loader.rpl, however, do not populate 
google.loader.callbacks.  They "must be loaded 
before the DOM" and aren't supposed to have per-library callbacks, which by 
(API) definition, are loaded after 
the DOM.  In short, this is an issue that could be addressed by changes to the 
loader code, or perhaps by 
some clever overwriting of google.load in our injector to add callbacks to 
google.loader.callbacks for modules 
added via google.loader.rpl.

P.S. google.loader.setOnLoadCallback still works as expected - it just requires 
all modules to be loaded.

P.P.S. Speaking of the benefits of being 'hosted,' iirc when I was testing some 
of this stuff, some of our release 
project svn files had the wrong content-types - e.g. text/plain.  I don't 
recall which ones, however.

Original comment by lem...@gmail.com on 4 Jun 2008 at 7:11

[GoogleCodeExporter]

Okay, I think you're on to something-- I'm meeting in person with the team 
today to
chat further about modifications necessary.

Original comment by pamela.fox on 5 Jun 2008 at 4:09

[GoogleCodeExporter]

After chatting with them and hearing their plans for the loader, I think it'd be
safer if we wrote our own function that looks similar to google.load - so that 
people
using the common loader follow a similar pattern when loading these libraries - 
but
so that we get total control of it. Here's a suggestion:
google.loadExtension("markermanager", "1.0", {callback: myFunc});

So I'd suggest the following, in each file.
// setup google namespace if not exist
// define google.loadExtension, let it accept a callback & version
// call google.loadedExtension (or whatever you proposed in r619 for callbacks).

I'd like if we could take in an array of extensions as well (as I talked about
earlier) and have one callback for all of them. I'd think most people would 
just want
to wait until every script had loaded before doing anything.

Original comment by pamela.fox on 9 Jun 2008 at 5:37

[GoogleCodeExporter]

Will do.  Are you sure we should use the top-level google namespace?  Maybe 
google.maps.UtilityLibrary?  It'd be 
nice to have someplace to call our own without stepping on any toes.

Original comment by lem...@gmail.com on 9 Jun 2008 at 9:39

[GoogleCodeExporter]

Sounds good.

Original comment by pamela.fox on 11 Jun 2008 at 12:36

[GoogleCodeExporter]

Unfortunately, *our* toes get stepped on in google.maps.  If we define 
google.maps.UtilityLoader early, then, when google.load("maps") is called, 
google.maps.UtilityLoader disappears.  In order to define it later, we would 
have to either load the loader later, which would complicate things 
considerably, or introduce a 
new global variable, which might not be too bad, as we would have total control 
of the namespace.  Instead, I chose google.extensions.maps in r641.

Original comment by lem...@gmail.com on 12 Jun 2008 at 6:38

[GoogleCodeExporter]

Good catch.

Original comment by pamela.fox on 14 Jun 2008 at 8:51

[GoogleCodeExporter]

I looked at your loader branch's modified lib code, one thing came up is that 
how to
avoid the libs step each other's toe. Right now all classes are actually in 
global
space, although no name conflicts now, it might be in the future, especially 
those
private "helper" functions.  Since we are looking at the name space, I think all
individual libs should wrapped in their own anonymous scope then export the 
pubic
classes, for example for drag zoom:

(function(){
  function DragZoomControl(opts_boxStyle, opts_other, opts_callbacks) {
  }

/*
 some helper functions (stuff in DragZoomUtil etc can be private here 
 and use whatever name necessary
 without having to checking with other libs to avoid toe stepping
*/

// then export  
if (google.extensions.maps.loader) {
  google.extensions.maps.loader.exportSymbol('DragZoom.Control', DragZoomControl);
  google.extensions.maps.loader.exportSymbol('DragZoom.Util', DragZoomUtil);
  google.extensions.maps.loader.loaded("dragzoom");
}

// if for compatibility we can still do the following 
// so the user can use new DragZoomControl directly.

window['DragZoomControl']=DragZoomControl;

})();

Original comment by nian...@gmail.com on 23 Sep 2008 at 11:15

[GoogleCodeExporter]

Yeah, that'd be nifty. Arguably itd be easier if all helper functions were 
prefixed 
with DragZoom_, e.g. But if you want to join the project and submit a patch, 
I'm all 
for it.

Note: We haven't merged this branch into trunk yet.

Original comment by pamela.fox on 25 Sep 2008 at 8:11

[GoogleCodeExporter]

Are we set on the namespace as 'google.extensions.maps.[sublib]'? 

From the recent discussion on this thread: 
http://groups.google.com/group/Google-Maps-API/browse_thread/thread/c6c5bd8f6441
a39e/f24f549218a279f5

It looks like it's a good idea to settle on a namespace earlier.

Original comment by nian...@gmail.com on 10 Nov 2008 at 2:11

[GoogleCodeExporter]

Nothing's carved in stone - it was initially gmapsUtilityLibrary, then
google.maps.UtilityLibrary, then google.extensions.maps.  We can't really use
google.maps because of issues with the official API overwriting anything 
pre-loaded
there.  Got a suggestion or preference?

Original comment by lem...@gmail.com on 10 Nov 2008 at 3:49

[GoogleCodeExporter]

I feel code like new google.extensions.maps.dragzoom.Control() may seems too 
long.
Also, google.extensions may have risk of been overwritten by some google APIs 
later
by same reason. I put 2 suggestions here:

1. gmaputils.[sublib] It's short. e.g. new gmapsutil.dragzoom.Control(), 3 
levels are
not bad;

2. google.mapexts.[sublib] or google.maputils.[sublib]. It's similar to coding
google.maps.* but unlikely to be overwritten. e.g. new 
google.mapexts.dragzoom.Control();

thoughts?

Original comment by nian...@gmail.com on 10 Nov 2008 at 5:00

[GoogleCodeExporter]

Fwiw I'd vote for google.maputils.[sublib].

Original comment by lem...@gmail.com on 10 Nov 2008 at 5:50