Mapstraction - Oct 2009 - Dynamic script loading problem (webkit browsers)

I''ve been tinkering with fixing the issue in webkit-based browsers
using mxn
script loading of the form:

<script src="source/mxn.js?(google)" ...

Some solutions are outlined on this page:
http://stevesouders.com/efws/window-onload.php

and I''ve summised that there are two possible solutions (neither really
pretty).

1. Assuming that the first mxn call will be to mxn.Mapstraction(...),
implement a wait function which blocks execution at the beginning of this
method until all dynamic scripts have been loaded.
This solution makes a large assumption but hides implementation from the
user.

2. Implement our own ''onready'' function for running mxn code,
possibly:

mxn.onload = function() { ...

which is coupled to script loaded callbacks and the document.ready function.
This solution should be quicker, but ''dirties'' the
user''s code and means
that other libraries'' onready functions can''t be used.

Thoughts anyone?

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091026/117f4361/attachment.htm>

Rob --

A question about the first solution: what are the side effects if  
mxn.Mapstraction is not the first call? For example, I''ve started maps
by first declaring a new mxn.LatLonPoint. It seems like that wouldn''t  
be a problem, as it''s just a data structure and does not contact  
providers. My guess is that that would be the case across the board.  
For example, a marker doesn''t become proprietary until it''s
added to
the map, which can''t happen until mxn.Mapstraction has been  
instantiated.

Are there ways that making the assumption about mxn.Mapstraction could  
cause problems?

--Adam
---
Adam DuVander
I like maps: http://mapscripting.com
I like simple: http://adamduvander.com

On Oct 26, 2009, at 2:55 PM, Rob wrote:
> I''ve been tinkering with fixing the issue in webkit-based browsers
> using mxn script loading of the form:
>
> <script src="source/mxn.js?(google)" ...
>
> Some solutions are outlined on this page:
> http://stevesouders.com/efws/window-onload.php
>
> and I''ve summised that there are two possible solutions (neither  
> really pretty).
>
> 1. Assuming that the first mxn call will be to mxn.Mapstraction 
> (...), implement a wait function which blocks execution at the  
> beginning of this method until all dynamic scripts have been loaded.
> This solution makes a large assumption but hides implementation from  
> the user.
>
> 2. Implement our own ''onready'' function for running mxn
code,
> possibly:
>
> mxn.onload = function() { ...
>
> which is coupled to script loaded callbacks and the document.ready  
> function.
> This solution should be quicker, but ''dirties'' the
user''s code and
> means that other libraries'' onready functions can''t be
used.
>
> Thoughts anyone?
>
> Rob
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com

We eventually solved this by explicitly loading the scripts we needed,
rather than relying on mxn to load them.

I''d be strongly against any sort of wait function. Speed is critical

I think the best solution is
a. make it clear what the problem is (it was a surprise to me)

b. make it clear different approaches to solve it, perhaps w/ examples
in common JS libraries like jquery, YUI, etc
perhaps the various solutions can be in the code but commented out.

c. leave it to the implementor which solution is right for their application

this obviously raises the complexity of implementation, but otherwise
every application has a solution imposed which may not be right
for them

BTW thanks for trying to tackle this, much appreciated



On Mon, Oct 26, 2009 at 21:55, Rob <mapstraction at thegecko.org>
wrote:
> I''ve been tinkering with fixing the issue in webkit-based browsers
using mxn
> script loading of the form:
>
> <script src="source/mxn.js?(google)" ...
>
> Some solutions are outlined on this page:
> http://stevesouders.com/efws/window-onload.php
>
> and I''ve summised that there are two possible solutions (neither
really
> pretty).
>
> 1. Assuming that the first mxn call will be to mxn.Mapstraction(...),
> implement a wait function which blocks execution at the beginning of this
> method until all dynamic scripts have been loaded.
> This solution makes a large assumption but hides implementation from the
> user.
>
> 2. Implement our own ''onready'' function for running mxn
code, possibly:
>
> mxn.onload = function() { ...
>
> which is coupled to script loaded callbacks and the document.ready
function.
> This solution should be quicker, but ''dirties'' the
user''s code and means
> that other libraries'' onready functions can''t be used.
>
> Thoughts anyone?
>
> Rob
>
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>
>

Thanks for the feedback, guys

@Adam, I''m not really sure. it would be great if that is the case, but
I
would need to test across all providers/objects :)

@Ed, the onload functions in other libraries don''t work either as it
seems
the document ready function fires too soon in webkit browsers with dynamic
scripts loading :/
I will run some tests, though as I haven''t tried them all...yet!

A wait function seems a common way of solving this issue and would only
happen once during the loading sequence, see http://labjs.com/

This was a function on the wishlist from the start of v2 to reduce
complexity for new developers, to only load scripts which will be used and
potentially to be extended to load the map provider scripts too (maybe one
day!).

Any other opinions, so I can direct my research a bit better? :)

Rob

2009/10/27 Ed Freyfogle <edf at sloan.mit.edu>
> We eventually solved this by explicitly loading the scripts we needed,
> rather than relying on mxn to load them.
>
> I''d be strongly against any sort of wait function. Speed is
critical
>
> I think the best solution is
> a. make it clear what the problem is (it was a surprise to me)
>
> b. make it clear different approaches to solve it, perhaps w/ examples
> in common JS libraries like jquery, YUI, etc
> perhaps the various solutions can be in the code but commented out.
>
> c. leave it to the implementor which solution is right for their
> application
>
> this obviously raises the complexity of implementation, but otherwise
> every application has a solution imposed which may not be right
> for them
>
> BTW thanks for trying to tackle this, much appreciated
>
>
>
> On Mon, Oct 26, 2009 at 21:55, Rob <mapstraction at thegecko.org>
wrote:
> > I''ve been tinkering with fixing the issue in webkit-based
browsers using
> mxn
> > script loading of the form:
> >
> > <script src="source/mxn.js?(google)" ...
> >
> > Some solutions are outlined on this page:
> > http://stevesouders.com/efws/window-onload.php
> >
> > and I''ve summised that there are two possible solutions
(neither really
> > pretty).
> >
> > 1. Assuming that the first mxn call will be to mxn.Mapstraction(...),
> > implement a wait function which blocks execution at the beginning of
this
> > method until all dynamic scripts have been loaded.
> > This solution makes a large assumption but hides implementation from
the
> > user.
> >
> > 2. Implement our own ''onready'' function for running
mxn code, possibly:
> >
> > mxn.onload = function() { ...
> >
> > which is coupled to script loaded callbacks and the document.ready
> function.
> > This solution should be quicker, but ''dirties'' the
user''s code and means
> > that other libraries'' onready functions can''t be
used.
> >
> > Thoughts anyone?
> >
> > Rob
> >
> > _______________________________________________
> > Mapstraction mailing list
> > Mapstraction at lists.mapstraction.com
> >
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091027/a50cd138/attachment.htm>

Several of the libraries themselves load up by dynamically adding more
script tags - how do they get around this issue?

2009/10/27 Rob <mapstraction at thegecko.org>
> Thanks for the feedback, guys
>
> @Adam, I''m not really sure. it would be great if that is the case,
but I
> would need to test across all providers/objects :)
>
> @Ed, the onload functions in other libraries don''t work either as
it seems
> the document ready function fires too soon in webkit browsers with dynamic
> scripts loading :/
> I will run some tests, though as I haven''t tried them all...yet!
>
> A wait function seems a common way of solving this issue and would only
> happen once during the loading sequence, see http://labjs.com/
>
> This was a function on the wishlist from the start of v2 to reduce
> complexity for new developers, to only load scripts which will be used and
> potentially to be extended to load the map provider scripts too (maybe one
> day!).
>
> Any other opinions, so I can direct my research a bit better? :)
>
> Rob
>
> 2009/10/27 Ed Freyfogle <edf at sloan.mit.edu>
>
> We eventually solved this by explicitly loading the scripts we needed,
>> rather than relying on mxn to load them.
>>
>> I''d be strongly against any sort of wait function. Speed is
critical
>>
>> I think the best solution is
>> a. make it clear what the problem is (it was a surprise to me)
>>
>> b. make it clear different approaches to solve it, perhaps w/ examples
>> in common JS libraries like jquery, YUI, etc
>> perhaps the various solutions can be in the code but commented out.
>>
>> c. leave it to the implementor which solution is right for their
>> application
>>
>> this obviously raises the complexity of implementation, but otherwise
>> every application has a solution imposed which may not be right
>> for them
>>
>> BTW thanks for trying to tackle this, much appreciated
>>
>>
>>
>> On Mon, Oct 26, 2009 at 21:55, Rob <mapstraction at thegecko.org>
wrote:
>> > I''ve been tinkering with fixing the issue in webkit-based
browsers using
>> mxn
>> > script loading of the form:
>> >
>> > <script src="source/mxn.js?(google)" ...
>> >
>> > Some solutions are outlined on this page:
>> > http://stevesouders.com/efws/window-onload.php
>> >
>> > and I''ve summised that there are two possible solutions
(neither really
>> > pretty).
>> >
>> > 1. Assuming that the first mxn call will be to
mxn.Mapstraction(...),
>> > implement a wait function which blocks execution at the beginning
of
>> this
>> > method until all dynamic scripts have been loaded.
>> > This solution makes a large assumption but hides implementation
from the
>> > user.
>> >
>> > 2. Implement our own ''onready'' function for
running mxn code, possibly:
>> >
>> > mxn.onload = function() { ...
>> >
>> > which is coupled to script loaded callbacks and the document.ready
>> function.
>> > This solution should be quicker, but ''dirties''
the user''s code and means
>> > that other libraries'' onready functions can''t be
used.
>> >
>> > Thoughts anyone?
>> >
>> > Rob
>> >
>> > _______________________________________________
>> > Mapstraction mailing list
>> > Mapstraction at lists.mapstraction.com
>> >
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>> >
>> >
>>
>
>
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>
>

-- 
Derek Fowler
m. +44 (0) 7966 512 369
e. dezfowler at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091027/0129b35e/attachment.htm>

I''ve only seen this in scriptaculous and YUI3 (seed).
In scriptaculous, I think (yet to confirm) that the race issue doesn''t
happen as the scripts being loaded are so small.

In YUI3 all user code is declared within a specific function, effectively
its own ''onload'' function.

What other libraries use this behaviour?


2009/10/27 Derek Fowler <dezfowler at gmail.com>
> Several of the libraries themselves load up by dynamically adding more
> script tags - how do they get around this issue?
>
> 2009/10/27 Rob <mapstraction at thegecko.org>
>
> Thanks for the feedback, guys
>>
>> @Adam, I''m not really sure. it would be great if that is the
case, but I
>> would need to test across all providers/objects :)
>>
>> @Ed, the onload functions in other libraries don''t work either
as it seems
>> the document ready function fires too soon in webkit browsers with
dynamic
>> scripts loading :/
>> I will run some tests, though as I haven''t tried them
all...yet!
>>
>> A wait function seems a common way of solving this issue and would only
>> happen once during the loading sequence, see http://labjs.com/
>>
>> This was a function on the wishlist from the start of v2 to reduce
>> complexity for new developers, to only load scripts which will be used
and
>> potentially to be extended to load the map provider scripts too (maybe
one
>> day!).
>>
>> Any other opinions, so I can direct my research a bit better? :)
>>
>> Rob
>>
>> 2009/10/27 Ed Freyfogle <edf at sloan.mit.edu>
>>
>> We eventually solved this by explicitly loading the scripts we needed,
>>> rather than relying on mxn to load them.
>>>
>>> I''d be strongly against any sort of wait function. Speed
is critical
>>>
>>> I think the best solution is
>>> a. make it clear what the problem is (it was a surprise to me)
>>>
>>> b. make it clear different approaches to solve it, perhaps w/
examples
>>> in common JS libraries like jquery, YUI, etc
>>> perhaps the various solutions can be in the code but commented out.
>>>
>>> c. leave it to the implementor which solution is right for their
>>> application
>>>
>>> this obviously raises the complexity of implementation, but
otherwise
>>> every application has a solution imposed which may not be right
>>> for them
>>>
>>> BTW thanks for trying to tackle this, much appreciated
>>>
>>>
>>>
>>> On Mon, Oct 26, 2009 at 21:55, Rob <mapstraction at
thegecko.org> wrote:
>>> > I''ve been tinkering with fixing the issue in
webkit-based browsers
>>> using mxn
>>> > script loading of the form:
>>> >
>>> > <script src="source/mxn.js?(google)" ...
>>> >
>>> > Some solutions are outlined on this page:
>>> > http://stevesouders.com/efws/window-onload.php
>>> >
>>> > and I''ve summised that there are two possible
solutions (neither really
>>> > pretty).
>>> >
>>> > 1. Assuming that the first mxn call will be to
mxn.Mapstraction(...),
>>> > implement a wait function which blocks execution at the
beginning of
>>> this
>>> > method until all dynamic scripts have been loaded.
>>> > This solution makes a large assumption but hides
implementation from
>>> the
>>> > user.
>>> >
>>> > 2. Implement our own ''onready'' function for
running mxn code, possibly:
>>> >
>>> > mxn.onload = function() { ...
>>> >
>>> > which is coupled to script loaded callbacks and the
document.ready
>>> function.
>>> > This solution should be quicker, but
''dirties'' the user''s code and
>>> means
>>> > that other libraries'' onready functions
can''t be used.
>>> >
>>> > Thoughts anyone?
>>> >
>>> > Rob
>>> >
>>> > _______________________________________________
>>> > Mapstraction mailing list
>>> > Mapstraction at lists.mapstraction.com
>>> >
>>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>> >
>>> >
>>>
>>
>>
>> _______________________________________________
>> Mapstraction mailing list
>> Mapstraction at lists.mapstraction.com
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>
>>
>
>
> --
> Derek Fowler
> m. +44 (0) 7966 512 369
> e. dezfowler at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091027/30415580/attachment-0001.htm>

I was actually referring to the map providers APIs - I''m pretty sure
they
dynamically inject script tags into the page so if you use that with
domReady how have we not seen that same issue just using the providers
directly? They must have some work around unless it''s slightly
different.

Derek

2009/10/27 Rob <mapstraction at thegecko.org>
> I''ve only seen this in scriptaculous and YUI3 (seed).
> In scriptaculous, I think (yet to confirm) that the race issue
doesn''t
> happen as the scripts being loaded are so small.
>
> In YUI3 all user code is declared within a specific function, effectively
> its own ''onload'' function.
>
> What other libraries use this behaviour?
>
>
> 2009/10/27 Derek Fowler <dezfowler at gmail.com>
>
> Several of the libraries themselves load up by dynamically adding more
>> script tags - how do they get around this issue?
>>
>> 2009/10/27 Rob <mapstraction at thegecko.org>
>>
>> Thanks for the feedback, guys
>>>
>>> @Adam, I''m not really sure. it would be great if that is
the case, but I
>>> would need to test across all providers/objects :)
>>>
>>> @Ed, the onload functions in other libraries don''t work
either as it
>>> seems the document ready function fires too soon in webkit browsers
with
>>> dynamic scripts loading :/
>>> I will run some tests, though as I haven''t tried them
all...yet!
>>>
>>> A wait function seems a common way of solving this issue and would
only
>>> happen once during the loading sequence, see http://labjs.com/
>>>
>>> This was a function on the wishlist from the start of v2 to reduce
>>> complexity for new developers, to only load scripts which will be
used and
>>> potentially to be extended to load the map provider scripts too
(maybe one
>>> day!).
>>>
>>> Any other opinions, so I can direct my research a bit better? :)
>>>
>>> Rob
>>>
>>> 2009/10/27 Ed Freyfogle <edf at sloan.mit.edu>
>>>
>>> We eventually solved this by explicitly loading the scripts we
needed,
>>>> rather than relying on mxn to load them.
>>>>
>>>> I''d be strongly against any sort of wait function.
Speed is critical
>>>>
>>>> I think the best solution is
>>>> a. make it clear what the problem is (it was a surprise to me)
>>>>
>>>> b. make it clear different approaches to solve it, perhaps w/
examples
>>>> in common JS libraries like jquery, YUI, etc
>>>> perhaps the various solutions can be in the code but commented
out.
>>>>
>>>> c. leave it to the implementor which solution is right for
their
>>>> application
>>>>
>>>> this obviously raises the complexity of implementation, but
otherwise
>>>> every application has a solution imposed which may not be right
>>>> for them
>>>>
>>>> BTW thanks for trying to tackle this, much appreciated
>>>>
>>>>
>>>>
>>>> On Mon, Oct 26, 2009 at 21:55, Rob <mapstraction at
thegecko.org> wrote:
>>>> > I''ve been tinkering with fixing the issue in
webkit-based browsers
>>>> using mxn
>>>> > script loading of the form:
>>>> >
>>>> > <script src="source/mxn.js?(google)" ...
>>>> >
>>>> > Some solutions are outlined on this page:
>>>> > http://stevesouders.com/efws/window-onload.php
>>>> >
>>>> > and I''ve summised that there are two possible
solutions (neither
>>>> really
>>>> > pretty).
>>>> >
>>>> > 1. Assuming that the first mxn call will be to
mxn.Mapstraction(...),
>>>> > implement a wait function which blocks execution at the
beginning of
>>>> this
>>>> > method until all dynamic scripts have been loaded.
>>>> > This solution makes a large assumption but hides
implementation from
>>>> the
>>>> > user.
>>>> >
>>>> > 2. Implement our own ''onready'' function
for running mxn code,
>>>> possibly:
>>>> >
>>>> > mxn.onload = function() { ...
>>>> >
>>>> > which is coupled to script loaded callbacks and the
document.ready
>>>> function.
>>>> > This solution should be quicker, but
''dirties'' the user''s code and
>>>> means
>>>> > that other libraries'' onready functions
can''t be used.
>>>> >
>>>> > Thoughts anyone?
>>>> >
>>>> > Rob
>>>> >
>>>> > _______________________________________________
>>>> > Mapstraction mailing list
>>>> > Mapstraction at lists.mapstraction.com
>>>> >
>>>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>>> >
>>>> >
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mapstraction mailing list
>>> Mapstraction at lists.mapstraction.com
>>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>>
>>>
>>
>>
>> --
>> Derek Fowler
>> m. +44 (0) 7966 512 369
>> e. dezfowler at gmail.com
>>
>
>

-- 
Derek Fowler
m. +44 (0) 7966 512 369
e. dezfowler at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091027/4438155c/attachment.htm>

I think the lazy-loading of a provider API is not possible unless the API
supports this explicitely (like google maps with their &async url
parameter).

I requested a similar feature for the cloudmade api, and their developer
suggested a general-purpose receipe for detecting the readyState of the
embedded api. This didn''t work however:

http://developers.cloudmade.com/issues/show/243

I also conducted experiments using object detection ? la if
(!window.GMap){setTimeOut()}, but it didn''t work either. It turned out
that
classname visible != class ready for instantiation.
Surely you could hack an advanded "API is loaded" detection, but then
you ''d
depend on a lot of API internas that might change quickly.

Franz


2009/10/27 Derek Fowler <dezfowler at gmail.com>
> I was actually referring to the map providers APIs - I''m pretty
sure they
> dynamically inject script tags into the page so if you use that with
> domReady how have we not seen that same issue just using the providers
> directly? They must have some work around unless it''s slightly
different.
>
> Derek
>
>
> 2009/10/27 Rob <mapstraction at thegecko.org>
>
>> I''ve only seen this in scriptaculous and YUI3 (seed).
>> In scriptaculous, I think (yet to confirm) that the race issue
doesn''t
>> happen as the scripts being loaded are so small.
>>
>> In YUI3 all user code is declared within a specific function,
effectively
>> its own ''onload'' function.
>>
>> What other libraries use this behaviour?
>>
>>
>> 2009/10/27 Derek Fowler <dezfowler at gmail.com>
>>
>> Several of the libraries themselves load up by dynamically adding more
>>> script tags - how do they get around this issue?
>>>
>>> 2009/10/27 Rob <mapstraction at thegecko.org>
>>>
>>> Thanks for the feedback, guys
>>>>
>>>> @Adam, I''m not really sure. it would be great if that
is the case, but I
>>>> would need to test across all providers/objects :)
>>>>
>>>> @Ed, the onload functions in other libraries don''t
work either as it
>>>> seems the document ready function fires too soon in webkit
browsers with
>>>> dynamic scripts loading :/
>>>> I will run some tests, though as I haven''t tried them
all...yet!
>>>>
>>>> A wait function seems a common way of solving this issue and
would only
>>>> happen once during the loading sequence, see http://labjs.com/
>>>>
>>>> This was a function on the wishlist from the start of v2 to
reduce
>>>> complexity for new developers, to only load scripts which will
be used and
>>>> potentially to be extended to load the map provider scripts too
(maybe one
>>>> day!).
>>>>
>>>> Any other opinions, so I can direct my research a bit better?
:)
>>>>
>>>> Rob
>>>>
>>>> 2009/10/27 Ed Freyfogle <edf at sloan.mit.edu>
>>>>
>>>> We eventually solved this by explicitly loading the scripts we
needed,
>>>>> rather than relying on mxn to load them.
>>>>>
>>>>> I''d be strongly against any sort of wait function.
Speed is critical
>>>>>
>>>>> I think the best solution is
>>>>> a. make it clear what the problem is (it was a surprise to
me)
>>>>>
>>>>> b. make it clear different approaches to solve it, perhaps
w/ examples
>>>>> in common JS libraries like jquery, YUI, etc
>>>>> perhaps the various solutions can be in the code but
commented out.
>>>>>
>>>>> c. leave it to the implementor which solution is right for
their
>>>>> application
>>>>>
>>>>> this obviously raises the complexity of implementation, but
otherwise
>>>>> every application has a solution imposed which may not be
right
>>>>> for them
>>>>>
>>>>> BTW thanks for trying to tackle this, much appreciated
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 26, 2009 at 21:55, Rob <mapstraction at
thegecko.org> wrote:
>>>>> > I''ve been tinkering with fixing the issue in
webkit-based browsers
>>>>> using mxn
>>>>> > script loading of the form:
>>>>> >
>>>>> > <script src="source/mxn.js?(google)" ...
>>>>> >
>>>>> > Some solutions are outlined on this page:
>>>>> > http://stevesouders.com/efws/window-onload.php
>>>>> >
>>>>> > and I''ve summised that there are two possible
solutions (neither
>>>>> really
>>>>> > pretty).
>>>>> >
>>>>> > 1. Assuming that the first mxn call will be to
mxn.Mapstraction(...),
>>>>> > implement a wait function which blocks execution at
the beginning of
>>>>> this
>>>>> > method until all dynamic scripts have been loaded.
>>>>> > This solution makes a large assumption but hides
implementation from
>>>>> the
>>>>> > user.
>>>>> >
>>>>> > 2. Implement our own ''onready''
function for running mxn code,
>>>>> possibly:
>>>>> >
>>>>> > mxn.onload = function() { ...
>>>>> >
>>>>> > which is coupled to script loaded callbacks and the
document.ready
>>>>> function.
>>>>> > This solution should be quicker, but
''dirties'' the user''s code and
>>>>> means
>>>>> > that other libraries'' onready functions
can''t be used.
>>>>> >
>>>>> > Thoughts anyone?
>>>>> >
>>>>> > Rob
>>>>> >
>>>>> > _______________________________________________
>>>>> > Mapstraction mailing list
>>>>> > Mapstraction at lists.mapstraction.com
>>>>> >
>>>>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>>>> >
>>>>> >
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mapstraction mailing list
>>>> Mapstraction at lists.mapstraction.com
>>>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Derek Fowler
>>> m. +44 (0) 7966 512 369
>>> e. dezfowler at gmail.com
>>>
>>
>>
>
>
> --
> Derek Fowler
> m. +44 (0) 7966 512 369
> e. dezfowler at gmail.com
>
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091028/f3e0f45f/attachment.htm>