Mapstraction - Jul 2008 - Extending Mapstraction for a new JavaScript Map API

Hi,

Is there a way to use Mapstraction for a new Dojo-based JavaScript API?
My company has a new such release (ArcGIS JavaScript API) and I will be
interested to integrate it with/in Mapstraction.
I''m not sure yet if approval for a full public access will be available
soon, so I guess the question for now is if I can use Mapstraction to do
that on my side, rather than to extend Mapstraction at this stage.

Thanks,
--bjh

On Mon, Jul 28, 2008 at 6:00 PM, Jean-Henry Berevoescu
<jberevoescu at esri.com> wrote:
>
> Hi,
>
> Is there a way to use Mapstraction for a new Dojo-based JavaScript API?
> My company has a new such release (ArcGIS JavaScript API) and I will be
> interested to integrate it with/in Mapstraction.
> I''m not sure yet if approval for a full public access will be
available
> soon, so I guess the question for now is if I can use Mapstraction to do
> that on my side, rather than to extend Mapstraction at this stage.
Hi Jean-Henry,
extending Mapstraction to call more API''s is fairly easy and
straight-forward. It would be great to include support for ESRI''s new
JS-API.

Let me know if you run into any issues.
Andrew

> -----Original Message-----
> From: ajturner at gmail.com [mailto:ajturner at gmail.com] On Behalf Of
Andrew
> Turner @ mapufacture
> Sent: Tuesday, July 29, 2008 12:54 PM
> To: Jean-Henry Berevoescu
> Cc: mapstraction at lists.mapstraction.com
> Subject: Re: [Mapstraction] Extending Mapstraction for a new
JavaScript
> Map API
> 
> On Mon, Jul 28, 2008 at 6:00 PM, Jean-Henry Berevoescu
> <jberevoescu at esri.com> wrote:
> >
> > Hi,
> >
> > Is there a way to use Mapstraction for a new Dojo-based JavaScript
API?
> > My company has a new such release (ArcGIS JavaScript API) and I will
be
> > interested to integrate it with/in Mapstraction.
> > I''m not sure yet if approval for a full public access will be
available
> > soon, so I guess the question for now is if I can use Mapstraction
to do
> > that on my side, rather than to extend Mapstraction at this stage.
> 
> Hi Jean-Henry,
> extending Mapstraction to call more API''s is fairly easy and
> straight-forward. It would be great to include support for ESRI''s
new
> JS-API.
> 
> Let me know if you run into any issues.
> Andrew
Hi Andrew,
Is there some documentation on this kind of extending Mapstraction?
It will be very helpful.

Thanks,
--bjh

On Tue, Jul 29, 2008 at 4:11 PM, Jean-Henry Berevoescu
<jberevoescu at esri.com> wrote:
> Hi Andrew,
> Is there some documentation on this kind of extending Mapstraction?
> It will be very helpful.
>
No, I have been behind on updating the documentation. However, the
typical "method" is to just walk through the functions and add the
appropriate equivalent "case" in all the switch statements. So this is
actually for modifying Mapstraction''s core functionality to support
your API, instead of just "extending" it.

Modifying Mapstraction to instead be extensible for any new API,
rather than requiring modification, is interesting.

> No, I have been behind on updating the documentation. However, the
> typical "method" is to just walk through the functions and add
the
> appropriate equivalent "case" in all the switch statements. So
this is
> actually for modifying Mapstraction''s core functionality to
support
> your API, instead of just "extending" it.
>
> Modifying Mapstraction to instead be extensible for any new API,
> rather than requiring modification, is interesting.
>   
Agreed, large numbers of switch statements is not very OO friendly and 
makes code more fragile and harder to maintain,
especially as support for new platforms is being added. It also makes it 
a bit of a bad idea to implement certain features
that are only supported by one specific mapping platform.

I ended up not using mapstraction in my project especially for that 
reason. This isn''t criticism (because I think mapstraction is
still a great library) but I think at some point the library would 
benefit from being split up into multiple files, like this:

mapstraction.js  -  containing the prototype base class with all common 
functionality and utility functions, and defining a common api.

mapstraction-google.js
mapstraction-yahoo.js
mapstraction-osm.js

etc which will all contain implementations of the current mapstraction 
api for the specific platform.  It could use either inheritance
so these platform specific classes extend the prototype of the main 
class in mapstraction.js, or the functionality in the base class could
delegate calls to the platform implementation classes.

This type of design has several advantages:
- code is easier to maintain and read. - it''s conducive to getting 
contributions and other maps support from other developers. They''ll be 
able to implement support for new
mapping platforms without the need to make any changes to the existing 
mapstraction code.
- developers can choose to include only the js files for platforms that 
they actually use in their app. If only google maps is used, all the
virtual earth/yahoo etc js files can be left out so pages will load 
faster and the server saves bandwidth.
- it''s possible to extend the api for certain platforms with features 
that are specific to that platform, without polluting the common api too 
much.
Currently the only way to do this would be to either hack away in 
mapstraction code, or get the native map object and implement these
features yourself with the platform native api, but that sort of defeats 
the purpose of using an abstraction library.
A developer might have the need for, say, some custom marker type used
in google maps. He could abstract the functionality for that, create a 
method for it in mapstraction-google.js and submit it back to the project.
A mapstraction/yahoo maps developer might see the announcement and think 
''hey, that can be done in yahoo maps too'', and submit a
yahoo implementation of the same feature. The api can gracefully handle 
situations where features aren''t supported for a certain platform,
and a wiki page or spreadsheet can document what is  supported by what 
platforms.

I believe modularizing the library will drive both development and more 
widespread use of mapstraction.
And I may be interested in contributing to these efforts if others 
believe they''re worthwhile. Personally I''d also love to
see it use jquery, but that''s a different debate.


Disclaimer: i haven''t worked with mapstraction for a while and
haven''t
been following the mailing list too closely, so these suggestions
may have already been discussed or beaten down before.

Peter

I think those are awesome suggestions and I think that they''d greatly
benefit the Mapstraction community in terms of ease of updates, ease of use
& debugging, and much cleaner code readability... Not to mention lower
barrier to entry for new mapping engines.

I''d be interested in helping too.


Beau

On Tue, Jul 29, 2008 at 3:05 PM, Peter Hulst <phulst at sbcglobal.net>
wrote:
>
>  No, I have been behind on updating the documentation. However, the
>> typical "method" is to just walk through the functions and
add the
>> appropriate equivalent "case" in all the switch statements.
So this is
>> actually for modifying Mapstraction''s core functionality to
support
>> your API, instead of just "extending" it.
>>
>> Modifying Mapstraction to instead be extensible for any new API,
>> rather than requiring modification, is interesting.
>>
>>
> Agreed, large numbers of switch statements is not very OO friendly and
> makes code more fragile and harder to maintain,
> especially as support for new platforms is being added. It also makes it a
> bit of a bad idea to implement certain features
> that are only supported by one specific mapping platform.
>
> I ended up not using mapstraction in my project especially for that reason.
> This isn''t criticism (because I think mapstraction is
> still a great library) but I think at some point the library would benefit
> from being split up into multiple files, like this:
>
> mapstraction.js  -  containing the prototype base class with all common
> functionality and utility functions, and defining a common api.
>
> mapstraction-google.js
> mapstraction-yahoo.js
> mapstraction-osm.js
>
> etc which will all contain implementations of the current mapstraction api
> for the specific platform.  It could use either inheritance
> so these platform specific classes extend the prototype of the main class
> in mapstraction.js, or the functionality in the base class could
> delegate calls to the platform implementation classes.
>
> This type of design has several advantages:
> - code is easier to maintain and read. - it''s conducive to getting
> contributions and other maps support from other developers.
They''ll be able
> to implement support for new
> mapping platforms without the need to make any changes to the existing
> mapstraction code.
> - developers can choose to include only the js files for platforms that
> they actually use in their app. If only google maps is used, all the
> virtual earth/yahoo etc js files can be left out so pages will load faster
> and the server saves bandwidth.
> - it''s possible to extend the api for certain platforms with
features that
> are specific to that platform, without polluting the common api too much.
> Currently the only way to do this would be to either hack away in
> mapstraction code, or get the native map object and implement these
> features yourself with the platform native api, but that sort of defeats
> the purpose of using an abstraction library.
> A developer might have the need for, say, some custom marker type used
> in google maps. He could abstract the functionality for that, create a
> method for it in mapstraction-google.js and submit it back to the project.
> A mapstraction/yahoo maps developer might see the announcement and think
> ''hey, that can be done in yahoo maps too'', and submit a
> yahoo implementation of the same feature. The api can gracefully handle
> situations where features aren''t supported for a certain platform,
> and a wiki page or spreadsheet can document what is  supported by what
> platforms.
>
> I believe modularizing the library will drive both development and more
> widespread use of mapstraction.
> And I may be interested in contributing to these efforts if others believe
> they''re worthwhile. Personally I''d also love to
> see it use jquery, but that''s a different debate.
>
>
> Disclaimer: i haven''t worked with mapstraction for a while and
haven''t been
> following the mailing list too closely, so these suggestions
> may have already been discussed or beaten down before.
>
> Peter
>
>
> _______________________________________________
> 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/20080729/c51b15ad/attachment.htm>

I don''t mind helping on the google side :-)

 

Rob Moran
Technical Development Manager

Opportunity Links, Trust Court, The Vision Park, Histon, Cambridge, CB24
9PW
T 01223 566 522 F 01223 500 281  www.opp-links.org.uk
<http://www.opp-links.org.uk%20> 

Opportunity Links LTD registered in England no: 3565647. Registered
Office: Trust Court, The Vision Park, Histon, Cambs. CB24 9PW

This email message is private and for use by the addressee only. It may
contain information, which is privileged and confidential. If you
receive this in error please return to sender by reply and delete the
message from your computer. You are not authorised to and must not
disclose, copy, distribute or retain the message or any part of it. 

________________________________

From: mapstraction-bounces at lists.mapstraction.com
[mailto:mapstraction-bounces at lists.mapstraction.com] On Behalf Of Beau
Gunderson
Sent: 30 July 2008 01:42
To: Peter Hulst
Cc: mapstraction at lists.mapstraction.com
Subject: Re: [Mapstraction] Extending Mapstraction for a new JavaScript
MapAPI

 

I think those are awesome suggestions and I think that they''d greatly
benefit the Mapstraction community in terms of ease of updates, ease of
use & debugging, and much cleaner code readability... Not to mention
lower barrier to entry for new mapping engines.

I''d be interested in helping too.


Beau

On Tue, Jul 29, 2008 at 3:05 PM, Peter Hulst <phulst at sbcglobal.net>
wrote:

	 

	No, I have been behind on updating the documentation. However,
the
	typical "method" is to just walk through the functions and add
the
	appropriate equivalent "case" in all the switch statements. So
this is
	actually for modifying Mapstraction''s core functionality to
support
	your API, instead of just "extending" it.
	
	Modifying Mapstraction to instead be extensible for any new API,
	rather than requiring modification, is interesting.
	 

Agreed, large numbers of switch statements is not very OO friendly and
makes code more fragile and harder to maintain,
especially as support for new platforms is being added. It also makes it
a bit of a bad idea to implement certain features
that are only supported by one specific mapping platform.

I ended up not using mapstraction in my project especially for that
reason. This isn''t criticism (because I think mapstraction is
still a great library) but I think at some point the library would
benefit from being split up into multiple files, like this:

mapstraction.js  -  containing the prototype base class with all common
functionality and utility functions, and defining a common api.

mapstraction-google.js
mapstraction-yahoo.js
mapstraction-osm.js

etc which will all contain implementations of the current mapstraction
api for the specific platform.  It could use either inheritance
so these platform specific classes extend the prototype of the main
class in mapstraction.js, or the functionality in the base class could
delegate calls to the platform implementation classes.

This type of design has several advantages:
- code is easier to maintain and read. - it''s conducive to getting
contributions and other maps support from other developers. They''ll be
able to implement support for new
mapping platforms without the need to make any changes to the existing
mapstraction code.
- developers can choose to include only the js files for platforms that
they actually use in their app. If only google maps is used, all the
virtual earth/yahoo etc js files can be left out so pages will load
faster and the server saves bandwidth.
- it''s possible to extend the api for certain platforms with features
that are specific to that platform, without polluting the common api too
much.
Currently the only way to do this would be to either hack away in
mapstraction code, or get the native map object and implement these
features yourself with the platform native api, but that sort of defeats
the purpose of using an abstraction library.
A developer might have the need for, say, some custom marker type used
in google maps. He could abstract the functionality for that, create a
method for it in mapstraction-google.js and submit it back to the
project.
A mapstraction/yahoo maps developer might see the announcement and think
''hey, that can be done in yahoo maps too'', and submit a
yahoo implementation of the same feature. The api can gracefully handle
situations where features aren''t supported for a certain platform,
and a wiki page or spreadsheet can document what is  supported by what
platforms.

I believe modularizing the library will drive both development and more
widespread use of mapstraction.
And I may be interested in contributing to these efforts if others
believe they''re worthwhile. Personally I''d also love to
see it use jquery, but that''s a different debate.


Disclaimer: i haven''t worked with mapstraction for a while and
haven''t
been following the mailing list too closely, so these suggestions
may have already been discussed or beaten down before.

Peter



_______________________________________________
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/20080730/2a33d0c6/attachment-0001.htm>

Sorry, an addition :)

Excellent suggestion, makes a lot of sense having a core API which has
the main functionality with potential stubs to hook into. The
map-specific files then enhancing this with their on implementations or
own specific functionality extending the base prototypes.

Personally, I love JQuery as a JS library, but integration would need to
be done carefully so mapstraction doesn''t rely on it forcing users to
choose JQuery over other JS libraries. Perhaps library specific
extensions again for JQuery, Moo, prototype, etc?

Cheers,

Rob

Rob Moran
Technical Development Manager
Opportunity Links, Trust Court, The Vision Park, Histon, Cambridge, CB24
9PW
T 01223 566 522 F 01223 500 281  www.opp-links.org.uk 
Opportunity Links LTD registered in England no: 3565647. Registered
Office: Trust Court, The Vision Park, Histon, Cambs. CB24 9PW

This email message is private and for use by the addressee only. It may
contain information, which is privileged and confidential. If you
receive this in error please return to sender by reply and delete the
message from your computer. You are not authorised to and must not
disclose, copy, distribute or retain the message or any part of it. 
-----Original Message-----
From: mapstraction-bounces at lists.mapstraction.com
[mailto:mapstraction-bounces at lists.mapstraction.com] On Behalf Of Peter
Hulst
Sent: 29 July 2008 23:06
Cc: mapstraction at lists.mapstraction.com
Subject: Re: [Mapstraction] Extending Mapstraction for a new JavaScript
Map API

> No, I have been behind on updating the documentation. However, the
> typical "method" is to just walk through the functions and add
the
> appropriate equivalent "case" in all the switch statements. So
this is
> actually for modifying Mapstraction''s core functionality to
support
> your API, instead of just "extending" it.
>
> Modifying Mapstraction to instead be extensible for any new API,
> rather than requiring modification, is interesting.
>   
Agreed, large numbers of switch statements is not very OO friendly and 
makes code more fragile and harder to maintain,
especially as support for new platforms is being added. It also makes it

a bit of a bad idea to implement certain features
that are only supported by one specific mapping platform.

I ended up not using mapstraction in my project especially for that 
reason. This isn''t criticism (because I think mapstraction is
still a great library) but I think at some point the library would 
benefit from being split up into multiple files, like this:

mapstraction.js  -  containing the prototype base class with all common 
functionality and utility functions, and defining a common api.

mapstraction-google.js
mapstraction-yahoo.js
mapstraction-osm.js

etc which will all contain implementations of the current mapstraction 
api for the specific platform.  It could use either inheritance
so these platform specific classes extend the prototype of the main 
class in mapstraction.js, or the functionality in the base class could
delegate calls to the platform implementation classes.

This type of design has several advantages:
- code is easier to maintain and read. - it''s conducive to getting 
contributions and other maps support from other developers. They''ll be 
able to implement support for new
mapping platforms without the need to make any changes to the existing 
mapstraction code.
- developers can choose to include only the js files for platforms that 
they actually use in their app. If only google maps is used, all the
virtual earth/yahoo etc js files can be left out so pages will load 
faster and the server saves bandwidth.
- it''s possible to extend the api for certain platforms with features 
that are specific to that platform, without polluting the common api too

much.
Currently the only way to do this would be to either hack away in 
mapstraction code, or get the native map object and implement these
features yourself with the platform native api, but that sort of defeats

the purpose of using an abstraction library.
A developer might have the need for, say, some custom marker type used
in google maps. He could abstract the functionality for that, create a 
method for it in mapstraction-google.js and submit it back to the
project.
A mapstraction/yahoo maps developer might see the announcement and think

''hey, that can be done in yahoo maps too'', and submit a
yahoo implementation of the same feature. The api can gracefully handle 
situations where features aren''t supported for a certain platform,
and a wiki page or spreadsheet can document what is  supported by what 
platforms.

I believe modularizing the library will drive both development and more 
widespread use of mapstraction.
And I may be interested in contributing to these efforts if others 
believe they''re worthwhile. Personally I''d also love to
see it use jquery, but that''s a different debate.


Disclaimer: i haven''t worked with mapstraction for a while and
haven''t
been following the mailing list too closely, so these suggestions
may have already been discussed or beaten down before.

Peter

_______________________________________________
Mapstraction mailing list
Mapstraction at lists.mapstraction.com
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com

Thanks all for the great ideas and offers to help. I think this is a
great move forward. I''ve included more specific responses below:


On Wed, Jul 30, 2008 at 9:31 AM, Rob Moran <Rob.Moran at opp-links.org.uk>
wrote:
>
> Personally, I love JQuery as a JS library, but integration would need to
> be done carefully so mapstraction doesn''t rely on it forcing users
to
> choose JQuery over other JS libraries. Perhaps library specific
> extensions again for JQuery, Moo, prototype, etc?
Right - Mapstraction shouldn''t depend on, or conflict with, any of the
other JS toolkits/libraries. There are only about 2 functions that
have been implemented in Mapstraction that have some overlap - most
notably the $() type selector.
> -----Original Message-----
> [mailto:mapstraction-bounces at lists.mapstraction.com] On Behalf Of Peter
>
> Agreed, large numbers of switch statements is not very OO friendly and
> makes code more fragile and harder to maintain,
> especially as support for new platforms is being added. It also makes it
> a bit of a bad idea to implement certain features
> that are only supported by one specific mapping platform.
Mapstraction was originally designed & developed for only 3 providers:
G-Y-M (ergo the logo). Things have definitely carried far beyond the
original library, which is great. But in this expansion, and as more
other libraries show up, it''s a good idea to properly redo this in
with better architecture.

Most of these changes will be, and should remain, transparent to the
"user" developer. The true goal is to keep the map-making easy, and
selectable.

I''ve just pushed up a number of patches & additions other users
have
sent in, I''ll actually send this out in a separate email to keep the
topics separate (for any other readers that won''t read this far). But
lets start discussing specific architectures/patterns to use here.

As Peter mentioned, there are at least two ways to go: inheritance or
decorator. Thoughts?

Andrew

Hi Everyone,

I''d like to re-iterate Peter''s point and say that I think the
major argument
for breaking up the library into individual files for each of the providers
is download size. Currently the percentage of the code you download, that is
ever actually called, is small and that just isn''t an efficient use of
bandwidth.

With regard to the pattern I don''t think inheritance or decorator are
correct in this situation. You''re not extending base classes or adding
new
functionality you''re implementing a particular interface of
lowest-common-denominator functionality so I think want''s needed is
more
like a bridge pattern. I think straying towards "implementing and
extending", adding increased functionality for providers that support it,
is
against the mission statement of mapstraction and removes the ability for
you to code your app and then switch providers with confidence that it will
all work. If you need extra features you should use a specific library, not
mapstraction.

Having said that I think the events system needs improvement as the native
APIs all support quite a lot of events, for example in a recent project I
found not having the "info bubble opened" event available for hooking
up to
be a real issue.

As for building it on a particular JavaScript library there isn''t much
point
as there is very little DOM manipulation code in mapstraction; it is mostly
dealing with native API objects and methods and they handle the DOM
manipulation and cross-browser issues themselves. It may be beneficial to
have plugins for the individual libraries available however, to provide more
seamless integration.

I''d be happy to help out with the new architecture, the improved events
system (if that''s done) and the Multimap implementation (as
that''s the API
I''ve worked with most recently).

Derek

On Wed, Jul 30, 2008 at 7:47 PM, Andrew Turner
<ajturner at highearthorbit.com>wrote:
> Thanks all for the great ideas and offers to help. I think this is a
> great move forward. I''ve included more specific responses below:
>
>
> On Wed, Jul 30, 2008 at 9:31 AM, Rob Moran <Rob.Moran at
opp-links.org.uk>
> wrote:
> >
> > Personally, I love JQuery as a JS library, but integration would need
to
> > be done carefully so mapstraction doesn''t rely on it forcing
users to
> > choose JQuery over other JS libraries. Perhaps library specific
> > extensions again for JQuery, Moo, prototype, etc?
>
> Right - Mapstraction shouldn''t depend on, or conflict with, any of
the
> other JS toolkits/libraries. There are only about 2 functions that
> have been implemented in Mapstraction that have some overlap - most
> notably the $() type selector.
>
> > -----Original Message-----
> > [mailto:mapstraction-bounces at lists.mapstraction.com] On Behalf Of
Peter
> >
> > Agreed, large numbers of switch statements is not very OO friendly and
> > makes code more fragile and harder to maintain,
> > especially as support for new platforms is being added. It also makes
it
> > a bit of a bad idea to implement certain features
> > that are only supported by one specific mapping platform.
>
> Mapstraction was originally designed & developed for only 3 providers:
> G-Y-M (ergo the logo). Things have definitely carried far beyond the
> original library, which is great. But in this expansion, and as more
> other libraries show up, it''s a good idea to properly redo this in
> with better architecture.
>
> Most of these changes will be, and should remain, transparent to the
> "user" developer. The true goal is to keep the map-making easy,
and
> selectable.
>
> I''ve just pushed up a number of patches & additions other
users have
> sent in, I''ll actually send this out in a separate email to keep
the
> topics separate (for any other readers that won''t read this far).
But
> lets start discussing specific architectures/patterns to use here.
>
> As Peter mentioned, there are at least two ways to go: inheritance or
> decorator. Thoughts?
>
> Andrew
> _______________________________________________
> 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/20080731/4b36c517/attachment.htm>

Hi all,

 

"abstract" objects in the core API extended into various flavours
could
be used as an interface for this with the added benefit of being able to
extend with decorators as needed.

I''m by no means an authority on design, but I''m guessing we
just need to
keep the design simple yet highly extensible without over engineering it
(the factory pattern could be used, but may make it quite complicated).

I''ll need to investigate the bridge pattern :-)

 

 

Rob Moran
Technical Development Manager

Opportunity Links, Trust Court, The Vision Park, Histon, Cambridge, CB24
9PW
T 01223 566 522 F 01223 500 281  www.opp-links.org.uk
<http://www.opp-links.org.uk%20> 

Opportunity Links LTD registered in England no: 3565647. Registered
Office: Trust Court, The Vision Park, Histon, Cambs. CB24 9PW

This email message is private and for use by the addressee only. It may
contain information, which is privileged and confidential. If you
receive this in error please return to sender by reply and delete the
message from your computer. You are not authorised to and must not
disclose, copy, distribute or retain the message or any part of it. 

________________________________

From: Derek Fowler [mailto:dezfowler at gmail.com] 
Sent: 31 July 2008 01:48
To: Andrew Turner
Cc: Rob Moran; mapstraction at lists.mapstraction.com
Subject: Re: [Mapstraction] Extending Mapstraction for a new JavaScript
Map API

 

Hi Everyone,

I''d like to re-iterate Peter''s point and say that I think the
major
argument for breaking up the library into individual files for each of
the providers is download size. Currently the percentage of the code you
download, that is ever actually called, is small and that just isn''t an
efficient use of bandwidth.

With regard to the pattern I don''t think inheritance or decorator are
correct in this situation. You''re not extending base classes or adding
new functionality you''re implementing a particular interface of
lowest-common-denominator functionality so I think want''s needed is
more
like a bridge pattern. I think straying towards "implementing and
extending", adding increased functionality for providers that support
it, is against the mission statement of mapstraction and removes the
ability for you to code your app and then switch providers with
confidence that it will all work. If you need extra features you should
use a specific library, not mapstraction.

Having said that I think the events system needs improvement as the
native APIs all support quite a lot of events, for example in a recent
project I found not having the "info bubble opened" event available
for
hooking up to be a real issue.

As for building it on a particular JavaScript library there isn''t much
point as there is very little DOM manipulation code in mapstraction; it
is mostly dealing with native API objects and methods and they handle
the DOM manipulation and cross-browser issues themselves. It may be
beneficial to have plugins for the individual libraries available
however, to provide more seamless integration.

I''d be happy to help out with the new architecture, the improved events
system (if that''s done) and the Multimap implementation (as
that''s the
API I''ve worked with most recently).

Derek

On Wed, Jul 30, 2008 at 7:47 PM, Andrew Turner
<ajturner at highearthorbit.com> wrote:

Thanks all for the great ideas and offers to help. I think this is a
great move forward. I''ve included more specific responses below:



On Wed, Jul 30, 2008 at 9:31 AM, Rob Moran <Rob.Moran at opp-links.org.uk>
wrote:
>
> Personally, I love JQuery as a JS library, but integration would need
to
> be done carefully so mapstraction doesn''t rely on it forcing users
to
> choose JQuery over other JS libraries. Perhaps library specific
> extensions again for JQuery, Moo, prototype, etc?
Right - Mapstraction shouldn''t depend on, or conflict with, any of the
other JS toolkits/libraries. There are only about 2 functions that
have been implemented in Mapstraction that have some overlap - most
notably the $() type selector.

> -----Original Message-----
> [mailto:mapstraction-bounces at lists.mapstraction.com] On Behalf Of
Peter
>
> Agreed, large numbers of switch statements is not very OO friendly and
> makes code more fragile and harder to maintain,
> especially as support for new platforms is being added. It also makes
it
> a bit of a bad idea to implement certain features
> that are only supported by one specific mapping platform.
Mapstraction was originally designed & developed for only 3 providers:
G-Y-M (ergo the logo). Things have definitely carried far beyond the
original library, which is great. But in this expansion, and as more
other libraries show up, it''s a good idea to properly redo this in
with better architecture.

Most of these changes will be, and should remain, transparent to the
"user" developer. The true goal is to keep the map-making easy, and
selectable.

I''ve just pushed up a number of patches & additions other users
have
sent in, I''ll actually send this out in a separate email to keep the
topics separate (for any other readers that won''t read this far). But
lets start discussing specific architectures/patterns to use here.

As Peter mentioned, there are at least two ways to go: inheritance or
decorator. Thoughts?

Andrew

_______________________________________________
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/20080731/bb1acaaf/attachment-0001.htm>

My point was that it shouldn''t be extensible at all, your core objects
define the set of methods and the provider specific code simply provides
implementations for those methods - that is the bridge pattern. Allowing
extensibility means you''ll end up with diverging sets of provider
specific
functionality which defeats the object of mapstraction.

I''m thinking that a possible way forward might be a compatibility level
where you have predefined sets of functionality e.g. level0 that all
providers would meet at least and then adding more advanced functionality
with increasing levels which provider specific code must implement *all* of
in order to comply.

You could the specify in your app what level you want to use and
mapstraction would allow access to only methods of that level and would
ensure that any provider you tried to load met that level and otherwise
would throw an error.

I''ll knock together a quick demo of what I mean and share with the list
when
it''s working.

Derek

On Thu, Jul 31, 2008 at 10:54 AM, Rob Moran <Rob.Moran at
opp-links.org.uk>wrote:
>  Hi all,
>
>
>
> "abstract" objects in the core API extended into various flavours
could be
> used as an interface for this with the added benefit of being able to
extend
> with decorators as needed.
>
> I''m by no means an authority on design, but I''m guessing
we just need to
> keep the design simple yet highly extensible without over engineering it
> (the factory pattern could be used, but may make it quite complicated).
>
> I''ll need to investigate the bridge pattern J
>
>
>
>
>
> *Rob Moran**
> *Technical Development Manager
>
> *Opportunity Links*, *Trust Court*, *The Vision Park*, *Histon*, *
> Cambridge*, *CB24 9PW*
> *T 01223 566 522* *F 01223 500 281*  www.opp-links.org.uk
> <http://www.opp-links.org.uk%20>
>
> Opportunity Links LTD registered in England no: 3565647. Registered Office:
> Trust Court, The Vision Park, Histon, Cambs. CB24 9PW
>
> This email message is private and for use by the addressee only. It may
> contain information, which is privileged and confidential. If you receive
> this in error please return to sender by reply and delete the message from
> your computer. You are not authorised to and must not  disclose, copy,
> distribute or retain the message or any part of it.
>   ------------------------------
>
> *From:* Derek Fowler [mailto:dezfowler at gmail.com]
> *Sent:* 31 July 2008 01:48
> *To:* Andrew Turner
> *Cc:* Rob Moran; mapstraction at lists.mapstraction.com
> *Subject:* Re: [Mapstraction] Extending Mapstraction for a new JavaScript
> Map API
>
>
>
> Hi Everyone,
>
>
> I''d like to re-iterate Peter''s point and say that I think
the major
> argument for breaking up the library into individual files for each of the
> providers is download size. Currently the percentage of the code you
> download, that is ever actually called, is small and that just
isn''t an
> efficient use of bandwidth.
>
> With regard to the pattern I don''t think inheritance or decorator
are
> correct in this situation. You''re not extending base classes or
adding new
> functionality you''re implementing a particular interface of
> lowest-common-denominator functionality so I think want''s needed
is more
> like a bridge pattern. I think straying towards "implementing and
> extending", adding increased functionality for providers that support
it, is
> against the mission statement of mapstraction and removes the ability for
> you to code your app and then switch providers with confidence that it will
> all work. If you need extra features you should use a specific library, not
> mapstraction.
>
> Having said that I think the events system needs improvement as the native
> APIs all support quite a lot of events, for example in a recent project I
> found not having the "info bubble opened" event available for
hooking up to
> be a real issue.
>
> As for building it on a particular JavaScript library there isn''t
much
> point as there is very little DOM manipulation code in mapstraction; it is
> mostly dealing with native API objects and methods and they handle the DOM
> manipulation and cross-browser issues themselves. It may be beneficial to
> have plugins for the individual libraries available however, to provide
more
> seamless integration.
>
> I''d be happy to help out with the new architecture, the improved
events
> system (if that''s done) and the Multimap implementation (as
that''s the API
> I''ve worked with most recently).
>
> Derek
>
> On Wed, Jul 30, 2008 at 7:47 PM, Andrew Turner <
> ajturner at highearthorbit.com> wrote:
>
> Thanks all for the great ideas and offers to help. I think this is a
> great move forward. I''ve included more specific responses below:
>
>
>
> On Wed, Jul 30, 2008 at 9:31 AM, Rob Moran <Rob.Moran at
opp-links.org.uk>
> wrote:
> >
> > Personally, I love JQuery as a JS library, but integration would need
to
> > be done carefully so mapstraction doesn''t rely on it forcing
users to
> > choose JQuery over other JS libraries. Perhaps library specific
> > extensions again for JQuery, Moo, prototype, etc?
>
> Right - Mapstraction shouldn''t depend on, or conflict with, any of
the
> other JS toolkits/libraries. There are only about 2 functions that
> have been implemented in Mapstraction that have some overlap - most
> notably the $() type selector.
>
>
> > -----Original Message-----
> > [mailto:mapstraction-bounces at lists.mapstraction.com] On Behalf Of
Peter
> >
>
> > Agreed, large numbers of switch statements is not very OO friendly and
> > makes code more fragile and harder to maintain,
> > especially as support for new platforms is being added. It also makes
it
> > a bit of a bad idea to implement certain features
> > that are only supported by one specific mapping platform.
>
> Mapstraction was originally designed & developed for only 3 providers:
> G-Y-M (ergo the logo). Things have definitely carried far beyond the
> original library, which is great. But in this expansion, and as more
> other libraries show up, it''s a good idea to properly redo this in
> with better architecture.
>
> Most of these changes will be, and should remain, transparent to the
> "user" developer. The true goal is to keep the map-making easy,
and
> selectable.
>
> I''ve just pushed up a number of patches & additions other
users have
> sent in, I''ll actually send this out in a separate email to keep
the
> topics separate (for any other readers that won''t read this far).
But
> lets start discussing specific architectures/patterns to use here.
>
> As Peter mentioned, there are at least two ways to go: inheritance or
> decorator. Thoughts?
>
> Andrew
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20080731/52166c92/attachment.htm>

Sounds good, a demo would probably make things clearer.

 

A lowest common denominator approach may restrict functionality a lot,
though. I like the compliance level idea.


Rob

 

Rob Moran
Technical Development Manager

Opportunity Links, Trust Court, The Vision Park, Histon, Cambridge, CB24
9PW
T 01223 566 522 F 01223 500 281  www.opp-links.org.uk
<http://www.opp-links.org.uk%20> 

Opportunity Links LTD registered in England no: 3565647. Registered
Office: Trust Court, The Vision Park, Histon, Cambs. CB24 9PW

This email message is private and for use by the addressee only. It may
contain information, which is privileged and confidential. If you
receive this in error please return to sender by reply and delete the
message from your computer. You are not authorised to and must not
disclose, copy, distribute or retain the message or any part of it. 

________________________________

From: Derek Fowler [mailto:dezfowler at gmail.com] 
Sent: 31 July 2008 12:03
To: Rob Moran
Cc: mapstraction at lists.mapstraction.com
Subject: Re: [Mapstraction] Extending Mapstraction for a new JavaScript
Map API

 

My point was that it shouldn''t be extensible at all, your core objects
define the set of methods and the provider specific code simply provides
implementations for those methods - that is the bridge pattern. Allowing
extensibility means you''ll end up with diverging sets of provider
specific functionality which defeats the object of mapstraction.

I''m thinking that a possible way forward might be a compatibility level
where you have predefined sets of functionality e.g. level0 that all
providers would meet at least and then adding more advanced
functionality with increasing levels which provider specific code must
implement *all* of in order to comply.

You could the specify in your app what level you want to use and
mapstraction would allow access to only methods of that level and would
ensure that any provider you tried to load met that level and otherwise
would throw an error.

I''ll knock together a quick demo of what I mean and share with the list
when it''s working.

Derek

On Thu, Jul 31, 2008 at 10:54 AM, Rob Moran <Rob.Moran at
opp-links.org.uk>
wrote:

Hi all,

 

"abstract" objects in the core API extended into various flavours
could
be used as an interface for this with the added benefit of being able to
extend with decorators as needed.

I''m by no means an authority on design, but I''m guessing we
just need to
keep the design simple yet highly extensible without over engineering it
(the factory pattern could be used, but may make it quite complicated).

I''ll need to investigate the bridge pattern :-)

 

 

Rob Moran
Technical Development Manager

Opportunity Links, Trust Court, The Vision Park, Histon, Cambridge, CB24
9PW
T 01223 566 522 F 01223 500 281  www.opp-links.org.uk
<http://www.opp-links.org.uk%20> 

Opportunity Links LTD registered in England no: 3565647. Registered
Office: Trust Court, The Vision Park, Histon, Cambs. CB24 9PW

This email message is private and for use by the addressee only. It may
contain information, which is privileged and confidential. If you
receive this in error please return to sender by reply and delete the
message from your computer. You are not authorised to and must not
disclose, copy, distribute or retain the message or any part of it. 

________________________________

From: Derek Fowler [mailto:dezfowler at gmail.com] 
Sent: 31 July 2008 01:48
To: Andrew Turner
Cc: Rob Moran; mapstraction at lists.mapstraction.com


Subject: Re: [Mapstraction] Extending Mapstraction for a new JavaScript
Map API

 

Hi Everyone,



I''d like to re-iterate Peter''s point and say that I think the
major
argument for breaking up the library into individual files for each of
the providers is download size. Currently the percentage of the code you
download, that is ever actually called, is small and that just isn''t an
efficient use of bandwidth.

With regard to the pattern I don''t think inheritance or decorator are
correct in this situation. You''re not extending base classes or adding
new functionality you''re implementing a particular interface of
lowest-common-denominator functionality so I think want''s needed is
more
like a bridge pattern. I think straying towards "implementing and
extending", adding increased functionality for providers that support
it, is against the mission statement of mapstraction and removes the
ability for you to code your app and then switch providers with
confidence that it will all work. If you need extra features you should
use a specific library, not mapstraction.

Having said that I think the events system needs improvement as the
native APIs all support quite a lot of events, for example in a recent
project I found not having the "info bubble opened" event available
for
hooking up to be a real issue.

As for building it on a particular JavaScript library there isn''t much
point as there is very little DOM manipulation code in mapstraction; it
is mostly dealing with native API objects and methods and they handle
the DOM manipulation and cross-browser issues themselves. It may be
beneficial to have plugins for the individual libraries available
however, to provide more seamless integration.

I''d be happy to help out with the new architecture, the improved events
system (if that''s done) and the Multimap implementation (as
that''s the
API I''ve worked with most recently).

Derek

On Wed, Jul 30, 2008 at 7:47 PM, Andrew Turner
<ajturner at highearthorbit.com> wrote:

Thanks all for the great ideas and offers to help. I think this is a
great move forward. I''ve included more specific responses below:



On Wed, Jul 30, 2008 at 9:31 AM, Rob Moran <Rob.Moran at opp-links.org.uk>
wrote:
>
> Personally, I love JQuery as a JS library, but integration would need
to
> be done carefully so mapstraction doesn''t rely on it forcing users
to
> choose JQuery over other JS libraries. Perhaps library specific
> extensions again for JQuery, Moo, prototype, etc?
Right - Mapstraction shouldn''t depend on, or conflict with, any of the
other JS toolkits/libraries. There are only about 2 functions that
have been implemented in Mapstraction that have some overlap - most
notably the $() type selector.

> -----Original Message-----
> [mailto:mapstraction-bounces at lists.mapstraction.com] On Behalf Of
Peter
>
> Agreed, large numbers of switch statements is not very OO friendly and
> makes code more fragile and harder to maintain,
> especially as support for new platforms is being added. It also makes
it
> a bit of a bad idea to implement certain features
> that are only supported by one specific mapping platform.
Mapstraction was originally designed & developed for only 3 providers:
G-Y-M (ergo the logo). Things have definitely carried far beyond the
original library, which is great. But in this expansion, and as more
other libraries show up, it''s a good idea to properly redo this in
with better architecture.

Most of these changes will be, and should remain, transparent to the
"user" developer. The true goal is to keep the map-making easy, and
selectable.

I''ve just pushed up a number of patches & additions other users
have
sent in, I''ll actually send this out in a separate email to keep the
topics separate (for any other readers that won''t read this far). But
lets start discussing specific architectures/patterns to use here.

As Peter mentioned, there are at least two ways to go: inheritance or
decorator. Thoughts?

Andrew

_______________________________________________
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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20080731/20ce5ae6/attachment-0001.htm>

Derek Fowler wrote:
> Hi Everyone,
> 
> I''d like to re-iterate Peter''s point and say that I think
the major
> argument for breaking up the library into individual files for each of 
> the providers is download size. Currently the percentage of the code you 
> download, that is ever actually called, is small and that just
isn''t an
> efficient use of bandwidth.
> [...]
Splitting the code into more modules/files would be great.

On our website we made the decision to strip out unneeded Mapstraction
code to reduce the filesize (and possibly what the browser has to
compile). It was a long manual process removing those ''if''
branches and
thus we rarely update our Mapstraction code.

We need the abstraction to be able to switch to another mapping provider
without rewriting all our code. But right now we only offer Google and
OpenStreetMap to our users.

The Mapstraction code from 1 year ago (heck, even 2 years) covers 90%
functions we currently use/need. Only custom info windows needed some
fiddling around.

I''m not proposing a ''lite'' version. I know that would
be quite hard to
implement.

marc tobias
http://www.nestoria.co.uk/oxford/house/sale -- Google Maps
http://www.nestoria.co.uk/isle-of-wight/house/sale -- OpenStreetMap

On Thu, Jul 31, 2008 at 7:03 AM, Derek Fowler <dezfowler at gmail.com>
wrote:
> My point was that it shouldn''t be extensible at all, your core
objects
> define the set of methods and the provider specific code simply provides
> implementations for those methods - that is the bridge pattern. Allowing
> extensibility means you''ll end up with diverging sets of provider
specific
> functionality which defeats the object of mapstraction.
>
> I''m thinking that a possible way forward might be a compatibility
level
> where you have predefined sets of functionality e.g. level0 that all
> providers would meet at least and then adding more advanced functionality
> with increasing levels which provider specific code must implement *all* of
> in order to comply.
>
While this sounds intriguing - I also wouldn''t want to complicate
Mapstraction - to the user developer or to the contributor to adding
new providers. The requirement of "compliance" is perhaps onerous and
not sure it''s necessary. I don''t think users need to be so
specific on
stating enforced levels of functionality they would be calling.

One thing to keep in mind as well is as new "general" functionality
becomes available, how will this be added. For example, new base
layers:

  http://mapstraction.com/demo-tiles.php

This would have to be first introduced into the base class, and then
each provider would have to implement this function as well.

If you can get a small demo/example that would be useful in
understanding the implications of this approach.

Thanks,
Andrew

Here you go...

http://dfowler.geeksbox.co.uk/demos/mapstraction/

No actual maps here - just a demo of the bridge style implementation and
compatibility level stuff i was talking about.

Apologies for the ton of alerts.

Derek

On Thu, Jul 31, 2008 at 4:58 PM, Andrew Turner @ mapufacture <
andrew at mapufacture.com> wrote:
> On Thu, Jul 31, 2008 at 7:03 AM, Derek Fowler <dezfowler at
gmail.com> wrote:
> > My point was that it shouldn''t be extensible at all, your
core objects
> > define the set of methods and the provider specific code simply
provides
> > implementations for those methods - that is the bridge pattern.
Allowing
> > extensibility means you''ll end up with diverging sets of
provider
> specific
> > functionality which defeats the object of mapstraction.
> >
> > I''m thinking that a possible way forward might be a
compatibility level
> > where you have predefined sets of functionality e.g. level0 that all
> > providers would meet at least and then adding more advanced
functionality
> > with increasing levels which provider specific code must implement
*all*
> of
> > in order to comply.
> >
>
> While this sounds intriguing - I also wouldn''t want to complicate
> Mapstraction - to the user developer or to the contributor to adding
> new providers. The requirement of "compliance" is perhaps onerous
and
> not sure it''s necessary. I don''t think users need to be
so specific on
> stating enforced levels of functionality they would be calling.
>
> One thing to keep in mind as well is as new "general"
functionality
> becomes available, how will this be added. For example, new base
> layers:
>
>   http://mapstraction.com/demo-tiles.php
>
> This would have to be first introduced into the base class, and then
> each provider would have to implement this function as well.
>
> If you can get a small demo/example that would be useful in
> understanding the implications of this approach.
>
> Thanks,
> Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20080801/86a01c17/attachment.htm>

I like it (other than the annoying alerts!).  This is a very clean way 
of providing the (IMHO) desirable separation of code for specific providers.

I like the way that you implemented the compatibility levels also - not 
being a real JS coder, I didn''t know that these functions existed.

I don''t think that this really adds complication for the people wanting
to add a new provider.  If anything, I would say the opposite: it sets 
down a standard which you must adhere to, avoiding the problem of not 
implementing a method because it wasn''t relevant to you, or whatever. 
With Derek''s implementation, you can just say "Have I got a Level
x
provider - yes or no", which seems straightforward to me (whether the 
provider implementation works or not is a different matter ;p).

I perhaps have slight reservations about it being a
''high-rise''
compatibility level (level 1 builds on level 0, L2 builds on L1 etc). 
For example, what if there are 3 features X,Y,Z, and api A implements X 
and Y, api B implements Y and Z.  (I don''t know what these might be, 
just bear with me).  You couldn''t use Derek''s system to model
this.
Perhaps instead you could have a ''baseLevel'' field in each
element of
compatLevels which says ''I have to implement everything listed here, as
well as everything listed in item baseLevel''s spec.  You''ve
then
effectively got subclasses of parent levels.

But hey - I probably am over-complicating things here - I tend to.  I 
just thought I''d add my thoughts in these early architecture 
discussions.  Let''s at least consider that this might be useful, even
if
just to discount it.

Double thumbs up :)


Andy
(not Andrew)

Derek Fowler wrote:
> Here you go...
> 
> http://dfowler.geeksbox.co.uk/demos/mapstraction/
> 
> No actual maps here - just a demo of the bridge style implementation and
> compatibility level stuff i was talking about.
> 
> Apologies for the ton of alerts.
> 
> Derek
> 
> On Thu, Jul 31, 2008 at 4:58 PM, Andrew Turner @ mapufacture <
> andrew at mapufacture.com> wrote:
> 
>> On Thu, Jul 31, 2008 at 7:03 AM, Derek Fowler <dezfowler at
gmail.com> wrote:
>>> My point was that it shouldn''t be extensible at all, your
core objects
>>> define the set of methods and the provider specific code simply
provides
>>> implementations for those methods - that is the bridge pattern.
Allowing
>>> extensibility means you''ll end up with diverging sets of
provider
>> specific
>>> functionality which defeats the object of mapstraction.
>>>
>>> I''m thinking that a possible way forward might be a
compatibility level
>>> where you have predefined sets of functionality e.g. level0 that
all
>>> providers would meet at least and then adding more advanced
functionality
>>> with increasing levels which provider specific code must implement
*all*
>> of
>>> in order to comply.
>>>
>> While this sounds intriguing - I also wouldn''t want to
complicate
>> Mapstraction - to the user developer or to the contributor to adding
>> new providers. The requirement of "compliance" is perhaps
onerous and
>> not sure it''s necessary. I don''t think users need to
be so specific on
>> stating enforced levels of functionality they would be calling.
>>
>> One thing to keep in mind as well is as new "general"
functionality
>> becomes available, how will this be added. For example, new base
>> layers:
>>
>>   http://mapstraction.com/demo-tiles.php
>>
>> This would have to be first introduced into the base class, and then
>> each provider would have to implement this function as well.
>>
>> If you can get a small demo/example that would be useful in
>> understanding the implications of this approach.
>>
>> Thanks,
>> Andrew
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com

Nice example.

With regard to the compatibility model, it may be better to have members
which outline if an implementation can undertake specific functionality.
e.g.:

CanDrawLine
CanDrawCircle

Which can be checked before undertaking that functionality. These
smaller flags can be abstracted into higher level compatibility checks
such as:

CanDrawGraphics (which checks the members above).

This may overcomplicate things but allows a finer control on the
limitations of each implementation.

With specific functionality, maybe it should all go into the core
library only if 2 or more implementations are ever likely to support it.
Specific functionality for a single provider which is never likely to be
supported by others should go in its specific library. But for now I
can''t see how that can be done neatly while supporting the
compatibility
model.
Possibly an extension point which returns a default of "not supported"
if the functionality isn''t found?

Cheers,

Rob

Rob Moran
Technical Development Manager
Opportunity Links, Trust Court, The Vision Park, Histon, Cambridge, CB24
9PW
T 01223 566 522 F 01223 500 281  www.opp-links.org.uk 
Opportunity Links LTD registered in England no: 3565647. Registered
Office: Trust Court, The Vision Park, Histon, Cambs. CB24 9PW

This email message is private and for use by the addressee only. It may
contain information, which is privileged and confidential. If you
receive this in error please return to sender by reply and delete the
message from your computer. You are not authorised to and must not
disclose, copy, distribute or retain the message or any part of it. 
-----Original Message-----
From: Turner, Andy [mailto:a.turner06 at imperial.ac.uk] 
Sent: 01 August 2008 08:24
To: Derek Fowler
Cc: andrew at mapufacture.com; Rob Moran;
mapstraction at lists.mapstraction.com
Subject: Re: [Mapstraction] Extending Mapstraction for a new JavaScript
Map API

I like it (other than the annoying alerts!).  This is a very clean way 
of providing the (IMHO) desirable separation of code for specific
providers.

I like the way that you implemented the compatibility levels also - not 
being a real JS coder, I didn''t know that these functions existed.

I don''t think that this really adds complication for the people wanting
to add a new provider.  If anything, I would say the opposite: it sets 
down a standard which you must adhere to, avoiding the problem of not 
implementing a method because it wasn''t relevant to you, or whatever. 
With Derek''s implementation, you can just say "Have I got a Level
x
provider - yes or no", which seems straightforward to me (whether the 
provider implementation works or not is a different matter ;p).

I perhaps have slight reservations about it being a
''high-rise''
compatibility level (level 1 builds on level 0, L2 builds on L1 etc). 
For example, what if there are 3 features X,Y,Z, and api A implements X 
and Y, api B implements Y and Z.  (I don''t know what these might be, 
just bear with me).  You couldn''t use Derek''s system to model
this.
Perhaps instead you could have a ''baseLevel'' field in each
element of
compatLevels which says ''I have to implement everything listed here, as
well as everything listed in item baseLevel''s spec.  You''ve
then
effectively got subclasses of parent levels.

But hey - I probably am over-complicating things here - I tend to.  I 
just thought I''d add my thoughts in these early architecture 
discussions.  Let''s at least consider that this might be useful, even
if

just to discount it.

Double thumbs up :)


Andy
(not Andrew)

Derek Fowler wrote:
> Here you go...
> 
> http://dfowler.geeksbox.co.uk/demos/mapstraction/
> 
> No actual maps here - just a demo of the bridge style implementation
and
> compatibility level stuff i was talking about.
> 
> Apologies for the ton of alerts.
> 
> Derek
> 
> On Thu, Jul 31, 2008 at 4:58 PM, Andrew Turner @ mapufacture <
> andrew at mapufacture.com> wrote:
> 
>> On Thu, Jul 31, 2008 at 7:03 AM, Derek Fowler <dezfowler at
gmail.com>
wrote:
>>> My point was that it shouldn''t be extensible at all, your
core
objects
>>> define the set of methods and the provider specific code simply
provides
>>> implementations for those methods - that is the bridge pattern.
Allowing
>>> extensibility means you''ll end up with diverging sets of
provider
>> specific
>>> functionality which defeats the object of mapstraction.
>>>
>>> I''m thinking that a possible way forward might be a
compatibility
level
>>> where you have predefined sets of functionality e.g. level0 that
all
>>> providers would meet at least and then adding more advanced
functionality
>>> with increasing levels which provider specific code must implement
*all*
>> of
>>> in order to comply.
>>>
>> While this sounds intriguing - I also wouldn''t want to
complicate
>> Mapstraction - to the user developer or to the contributor to adding
>> new providers. The requirement of "compliance" is perhaps
onerous and
>> not sure it''s necessary. I don''t think users need to
be so specific
on
>> stating enforced levels of functionality they would be calling.
>>
>> One thing to keep in mind as well is as new "general"
functionality
>> becomes available, how will this be added. For example, new base
>> layers:
>>
>>   http://mapstraction.com/demo-tiles.php
>>
>> This would have to be first introduced into the base class, and then
>> each provider would have to implement this function as well.
>>
>> If you can get a small demo/example that would be useful in
>> understanding the implications of this approach.
>>
>> Thanks,
>> Andrew
>>
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com

You could quite easily support both types of compatibility, general levels
and a more fine grain specification e.g.

var m1 = new Mapstraction(''google'', { level: 1 } );

var m2 = new Mapstraction(''google'', { require: [
''markers'', ''polylines'' ] }
);

As for functionality only supported by a small number of providers, if
it''s
particularly useful functionality the Mapstraction core should implement the
functionality itself to fill in the holes in the other providers and smooth
out the support. In the same way the JavaScript libraries fill in the holes
in browser DOM implementations by providing their own.

I think there are a few examples of this in Mapstraction already,
autoCenterAndZoom for example is probably supported natively in most of the
APIs but Mapstraction uses its own implementation.

Here''s another little demo for you guys to take a look at...

http://dfowler.geeksbox.co.uk/demos/mapstraction/checkLoaded.htm

Trying to address this repeated code that is at the start of each of the
methods in Mapstraction...

if(this.loaded[this.api] === false) {
>     var me = this;
>     this.onload[this.api].push( function() { me.addLargeControls(); } );
>     return;
> }

...and turn it into this...

if (this.checkLoad(arguments)) return;


The former has to be maintained whenever a new argument is added to the
function, I''ve illustrated that problem in the demo where the function
is
called with an undeclared argument and the result is an undefined in the
alert because that argument isn''t passed to the onload.

In the latter the arguments object is simply passed to the onload and the
actual call is recreated by doing this...

funcDetails.callee.apply(scope, funcDetails);

Derek

On Sat, Aug 2, 2008 at 2:44 PM, Rob Moran <Rob.Moran at
opp-links.org.uk>wrote:
> Nice example.
>
> With regard to the compatibility model, it may be better to have members
> which outline if an implementation can undertake specific functionality.
> e.g.:
>
> CanDrawLine
> CanDrawCircle
>
> Which can be checked before undertaking that functionality. These
> smaller flags can be abstracted into higher level compatibility checks
> such as:
>
> CanDrawGraphics (which checks the members above).
>
> This may overcomplicate things but allows a finer control on the
> limitations of each implementation.
>
> With specific functionality, maybe it should all go into the core
> library only if 2 or more implementations are ever likely to support it.
> Specific functionality for a single provider which is never likely to be
> supported by others should go in its specific library. But for now I
> can''t see how that can be done neatly while supporting the
compatibility
> model.
> Possibly an extension point which returns a default of "not
supported"
> if the functionality isn''t found?
>
> Cheers,
>
> Rob
>
> Rob Moran
> Technical Development Manager
> Opportunity Links, Trust Court, The Vision Park, Histon, Cambridge, CB24
> 9PW
> T 01223 566 522 F 01223 500 281  www.opp-links.org.uk
> Opportunity Links LTD registered in England no: 3565647. Registered
> Office: Trust Court, The Vision Park, Histon, Cambs. CB24 9PW
>
> This email message is private and for use by the addressee only. It may
> contain information, which is privileged and confidential. If you
> receive this in error please return to sender by reply and delete the
> message from your computer. You are not authorised to and must not
> disclose, copy, distribute or retain the message or any part of it.
> -----Original Message-----
> From: Turner, Andy [mailto:a.turner06 at imperial.ac.uk]
> Sent: 01 August 2008 08:24
> To: Derek Fowler
> Cc: andrew at mapufacture.com; Rob Moran;
> mapstraction at lists.mapstraction.com
> Subject: Re: [Mapstraction] Extending Mapstraction for a new JavaScript
> Map API
>
> I like it (other than the annoying alerts!).  This is a very clean way
> of providing the (IMHO) desirable separation of code for specific
> providers.
>
> I like the way that you implemented the compatibility levels also - not
> being a real JS coder, I didn''t know that these functions existed.
>
> I don''t think that this really adds complication for the people
wanting
> to add a new provider.  If anything, I would say the opposite: it sets
> down a standard which you must adhere to, avoiding the problem of not
> implementing a method because it wasn''t relevant to you, or
whatever.
> With Derek''s implementation, you can just say "Have I got a
Level x
> provider - yes or no", which seems straightforward to me (whether the
> provider implementation works or not is a different matter ;p).
>
> I perhaps have slight reservations about it being a
''high-rise''
> compatibility level (level 1 builds on level 0, L2 builds on L1 etc).
> For example, what if there are 3 features X,Y,Z, and api A implements X
> and Y, api B implements Y and Z.  (I don''t know what these might
be,
> just bear with me).  You couldn''t use Derek''s system to
model this.
> Perhaps instead you could have a ''baseLevel'' field in
each element of
> compatLevels which says ''I have to implement everything listed
here, as
> well as everything listed in item baseLevel''s spec. 
You''ve then
> effectively got subclasses of parent levels.
>
> But hey - I probably am over-complicating things here - I tend to.  I
> just thought I''d add my thoughts in these early architecture
> discussions.  Let''s at least consider that this might be useful,
even if
>
> just to discount it.
>
> Double thumbs up :)
>
>
> Andy
> (not Andrew)
>
> Derek Fowler wrote:
> > Here you go...
> >
> > http://dfowler.geeksbox.co.uk/demos/mapstraction/
> >
> > No actual maps here - just a demo of the bridge style implementation
> and
> > compatibility level stuff i was talking about.
> >
> > Apologies for the ton of alerts.
> >
> > Derek
> >
> > On Thu, Jul 31, 2008 at 4:58 PM, Andrew Turner @ mapufacture <
> > andrew at mapufacture.com> wrote:
> >
> >> On Thu, Jul 31, 2008 at 7:03 AM, Derek Fowler <dezfowler at
gmail.com>
> wrote:
> >>> My point was that it shouldn''t be extensible at all,
your core
> objects
> >>> define the set of methods and the provider specific code
simply
> provides
> >>> implementations for those methods - that is the bridge
pattern.
> Allowing
> >>> extensibility means you''ll end up with diverging sets
of provider
> >> specific
> >>> functionality which defeats the object of mapstraction.
> >>>
> >>> I''m thinking that a possible way forward might be a
compatibility
> level
> >>> where you have predefined sets of functionality e.g. level0
that all
> >>> providers would meet at least and then adding more advanced
> functionality
> >>> with increasing levels which provider specific code must
implement
> *all*
> >> of
> >>> in order to comply.
> >>>
> >> While this sounds intriguing - I also wouldn''t want to
complicate
> >> Mapstraction - to the user developer or to the contributor to
adding
> >> new providers. The requirement of "compliance" is
perhaps onerous and
> >> not sure it''s necessary. I don''t think users
need to be so specific
> on
> >> stating enforced levels of functionality they would be calling.
> >>
> >> One thing to keep in mind as well is as new "general"
functionality
> >> becomes available, how will this be added. For example, new base
> >> layers:
> >>
> >>   http://mapstraction.com/demo-tiles.php
> >>
> >> This would have to be first introduced into the base class, and
then
> >> each provider would have to implement this function as well.
> >>
> >> If you can get a small demo/example that would be useful in
> >> understanding the implications of this approach.
> >>
> >> Thanks,
> >> Andrew
> >>
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20080803/79d82cb2/attachment.htm>

This is looking really great - the API is staying clean (priority)
while making it easy to add Providers.

Still have to think through what "Compatibility" levels mean. Perhaps
even looking at some of the work we did for breaking up functionality
in defining the KML spec in the OGC (core, styling, 3D, metadata,
etc.) that may have a parallel here in JS/slippy map space.



On Sun, Aug 3, 2008 at 10:30 AM, Derek Fowler <dezfowler at gmail.com>
wrote:
> You could quite easily support both types of compatibility, general levels
> and a more fine grain specification e.g.
>
> var m1 = new Mapstraction(''google'', { level: 1 } );
>
> var m2 = new Mapstraction(''google'', { require: [
''markers'', ''polylines'' ] }
> );
>
> As for functionality only supported by a small number of providers, if
it''s
> particularly useful functionality the Mapstraction core should implement
the
> functionality itself to fill in the holes in the other providers and smooth
> out the support. In the same way the JavaScript libraries fill in the holes
> in browser DOM implementations by providing their own.
>
> I think there are a few examples of this in Mapstraction already,
> autoCenterAndZoom for example is probably supported natively in most of the
> APIs but Mapstraction uses its own implementation.
>
> Here''s another little demo for you guys to take a look at...
>
> http://dfowler.geeksbox.co.uk/demos/mapstraction/checkLoaded.htm
>
> Trying to address this repeated code that is at the start of each of the
> methods in Mapstraction...
>
>> if(this.loaded[this.api] === false) {
>>     var me = this;
>>     this.onload[this.api].push( function() { me.addLargeControls(); }
);
>>     return;
>> }
>
> ...and turn it into this...
>
>> if (this.checkLoad(arguments)) return;
>
> The former has to be maintained whenever a new argument is added to the
> function, I''ve illustrated that problem in the demo where the
function is
> called with an undeclared argument and the result is an undefined in the
> alert because that argument isn''t passed to the onload.
>
> In the latter the arguments object is simply passed to the onload and the
> actual call is recreated by doing this...
>
> funcDetails.callee.apply(scope, funcDetails);
>
> Derek
>
> On Sat, Aug 2, 2008 at 2:44 PM, Rob Moran <Rob.Moran at
opp-links.org.uk>
> wrote:
>>
>> Nice example.
>>
>> With regard to the compatibility model, it may be better to have
members
>> which outline if an implementation can undertake specific
functionality.
>> e.g.:
>>
>> CanDrawLine
>> CanDrawCircle
>>
>> Which can be checked before undertaking that functionality. These
>> smaller flags can be abstracted into higher level compatibility checks
>> such as:
>>
>> CanDrawGraphics (which checks the members above).
>>
>> This may overcomplicate things but allows a finer control on the
>> limitations of each implementation.
>>
>> With specific functionality, maybe it should all go into the core
>> library only if 2 or more implementations are ever likely to support
it.
>> Specific functionality for a single provider which is never likely to
be
>> supported by others should go in its specific library. But for now I
>> can''t see how that can be done neatly while supporting the
compatibility
>> model.
>> Possibly an extension point which returns a default of "not
supported"
>> if the functionality isn''t found?
>>
>> Cheers,
>>
>> Rob
>>
>> Rob Moran
>> Technical Development Manager
>> Opportunity Links, Trust Court, The Vision Park, Histon, Cambridge,
CB24
>> 9PW
>> T 01223 566 522 F 01223 500 281  www.opp-links.org.uk
>> Opportunity Links LTD registered in England no: 3565647. Registered
>> Office: Trust Court, The Vision Park, Histon, Cambs. CB24 9PW
>>
>> This email message is private and for use by the addressee only. It may
>> contain information, which is privileged and confidential. If you
>> receive this in error please return to sender by reply and delete the
>> message from your computer. You are not authorised to and must not
>> disclose, copy, distribute or retain the message or any part of it.
>> -----Original Message-----
>> From: Turner, Andy [mailto:a.turner06 at imperial.ac.uk]
>> Sent: 01 August 2008 08:24
>> To: Derek Fowler
>> Cc: andrew at mapufacture.com; Rob Moran;
>> mapstraction at lists.mapstraction.com
>> Subject: Re: [Mapstraction] Extending Mapstraction for a new JavaScript
>> Map API
>>
>> I like it (other than the annoying alerts!).  This is a very clean way
>> of providing the (IMHO) desirable separation of code for specific
>> providers.
>>
>> I like the way that you implemented the compatibility levels also - not
>> being a real JS coder, I didn''t know that these functions
existed.
>>
>> I don''t think that this really adds complication for the
people wanting
>> to add a new provider.  If anything, I would say the opposite: it sets
>> down a standard which you must adhere to, avoiding the problem of not
>> implementing a method because it wasn''t relevant to you, or
whatever.
>> With Derek''s implementation, you can just say "Have I got
a Level x
>> provider - yes or no", which seems straightforward to me (whether
the
>> provider implementation works or not is a different matter ;p).
>>
>> I perhaps have slight reservations about it being a
''high-rise''
>> compatibility level (level 1 builds on level 0, L2 builds on L1 etc).
>> For example, what if there are 3 features X,Y,Z, and api A implements X
>> and Y, api B implements Y and Z.  (I don''t know what these
might be,
>> just bear with me).  You couldn''t use Derek''s system
to model this.
>> Perhaps instead you could have a ''baseLevel'' field in
each element of
>> compatLevels which says ''I have to implement everything listed
here, as
>> well as everything listed in item baseLevel''s spec. 
You''ve then
>> effectively got subclasses of parent levels.
>>
>> But hey - I probably am over-complicating things here - I tend to.  I
>> just thought I''d add my thoughts in these early architecture
>> discussions.  Let''s at least consider that this might be
useful, even if
>>
>> just to discount it.
>>
>> Double thumbs up :)
>>
>>
>> Andy
>> (not Andrew)
>>
>> Derek Fowler wrote:
>> > Here you go...
>> >
>> > http://dfowler.geeksbox.co.uk/demos/mapstraction/
>> >
>> > No actual maps here - just a demo of the bridge style
implementation
>> and
>> > compatibility level stuff i was talking about.
>> >
>> > Apologies for the ton of alerts.
>> >
>> > Derek
>> >
>> > On Thu, Jul 31, 2008 at 4:58 PM, Andrew Turner @ mapufacture <
>> > andrew at mapufacture.com> wrote:
>> >
>> >> On Thu, Jul 31, 2008 at 7:03 AM, Derek Fowler <dezfowler at
gmail.com>
>> wrote:
>> >>> My point was that it shouldn''t be extensible at
all, your core
>> objects
>> >>> define the set of methods and the provider specific code
simply
>> provides
>> >>> implementations for those methods - that is the bridge
pattern.
>> Allowing
>> >>> extensibility means you''ll end up with diverging
sets of provider
>> >> specific
>> >>> functionality which defeats the object of mapstraction.
>> >>>
>> >>> I''m thinking that a possible way forward might be
a compatibility
>> level
>> >>> where you have predefined sets of functionality e.g.
level0 that all
>> >>> providers would meet at least and then adding more
advanced
>> functionality
>> >>> with increasing levels which provider specific code must
implement
>> *all*
>> >> of
>> >>> in order to comply.
>> >>>
>> >> While this sounds intriguing - I also wouldn''t want
to complicate
>> >> Mapstraction - to the user developer or to the contributor to
adding
>> >> new providers. The requirement of "compliance" is
perhaps onerous and
>> >> not sure it''s necessary. I don''t think users
need to be so specific
>> on
>> >> stating enforced levels of functionality they would be
calling.
>> >>
>> >> One thing to keep in mind as well is as new
"general" functionality
>> >> becomes available, how will this be added. For example, new
base
>> >> layers:
>> >>
>> >>   http://mapstraction.com/demo-tiles.php
>> >>
>> >> This would have to be first introduced into the base class,
and then
>> >> each provider would have to implement this function as well.
>> >>
>> >> If you can get a small demo/example that would be useful in
>> >> understanding the implications of this approach.
>> >>
>> >> Thanks,
>> >> Andrew
>> >>
>> >
>> >
>> >
>>
------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > 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
>
>
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>
>


-- 
Andrew Turner
mobile: 248.982.3609
andrew at mapufacture.com
http://highearthorbit.com

http://mapufacture.com Helping build the Geospatial Web
Introduction to Neogeography - http://oreilly.com/catalog/neogeography