based on feedback - just rolling with what we have. Move can always happen later: http://mapstraction.com/svn/mxn -- Andrew Turner mobile: 248.982.3609 andrew at fortiusone.com http://highearthorbit.com http://geocommons.com Helping build the Geospatial Web Introduction to Neogeography - http://oreilly.com/catalog/neogeography
On Fri, Apr 24, 2009 at 4:57 AM, Franz Buchinger <fbuchinger at gmail.com> wrote:> Hi Andrew, > > as a recent, but interested follower of mapstraction I''m curious about the > purpose of this mapstraction branch. > > Is this basically a more modular mapstraction version (i.e. one .js file for > each map provider --> you only need to include the providers you want to > use)? >Excellent question. There have been several objectives of the new architecture: - modular files: allows a developer to only include providers that will be used - modular code: developers can focus on code per provider and easier to maintain rather than monolithic switch statements - tidier code It''s even better outlined here: http://mapstraction.com/news/mxn-v2-architecture/ For more info - Rob has been adding to the http://mapstraction.com/news/ page - so definitely check that out> Is there any roadmap for further releases?Not as such yet. Want to first get this release out as soon as possible - then we should all definitely brainstorm on what the next steps are.> > nice regards, > > Franz > > 2009/4/24 Andrew Turner <ajturner at highearthorbit.com> >> >> based on feedback - just rolling with what we have. Move can always >> happen later: >> >> http://mapstraction.com/svn/mxn >> >> >> >> -- >> Andrew Turner >> mobile: 248.982.3609 >> andrew at fortiusone.com >> http://highearthorbit.com >> >> http://geocommons.com ? ? ? ? ? Helping build the Geospatial Web >> Introduction to Neogeography - http://oreilly.com/catalog/neogeography >> _______________________________________________ >> 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 fortiusone.com http://highearthorbit.com http://geocommons.com Helping build the Geospatial Web Introduction to Neogeography - http://oreilly.com/catalog/neogeography
Thanks for pointing this out. I really appreciate the new architecture, because it makes adding new providers much easier and the library itself much more flexible. However it appears that some silent changes to the architecture proposed in http://mapstraction.com/news/mxn-v2-architecture/ occured: - the provider script template doesn''t mention the LatLonPoint/Marker/Polyline objects that are implemented in your mxn.google.js script. It is not quite clear which methods have to be implemented mandatory by a provider plugin. - $.Module.prototype.toGoogle in the provider template seems to be obsolete, because now the functional inheritance/extension pattern is used. And you use toProprietary/fromProprietary methods for converting mapstraction objects to native provider objects. Can/Should I use mapstraction modules to implement additional map interaction features? E.g. I want a user to interactively draw polygons in a map, which are composed of polylines and markers. Can you please update the preliminary API documentation? nice regards, Franz 2009/4/25 Andrew Turner <ajturner at highearthorbit.com>> On Fri, Apr 24, 2009 at 4:57 AM, Franz Buchinger <fbuchinger at gmail.com> > wrote: > > Hi Andrew, > > > > as a recent, but interested follower of mapstraction I''m curious about > the > > purpose of this mapstraction branch. > > > > Is this basically a more modular mapstraction version (i.e. one .js file > for > > each map provider --> you only need to include the providers you want to > > use)? > > > > Excellent question. > > There have been several objectives of the new architecture: > - modular files: allows a developer to only include providers that will be > used > - modular code: developers can focus on code per provider and easier > to maintain rather than monolithic switch statements > - tidier code > > It''s even better outlined here: > http://mapstraction.com/news/mxn-v2-architecture/ > > For more info - Rob has been adding to the > http://mapstraction.com/news/ page - so definitely check that out > > > Is there any roadmap for further releases? > > Not as such yet. Want to first get this release out as soon as > possible - then we should all definitely brainstorm on what the next > steps are. > > > > > > nice regards, > > > > Franz > > > > 2009/4/24 Andrew Turner <ajturner at highearthorbit.com> > >> > >> based on feedback - just rolling with what we have. Move can always > >> happen later: > >> > >> http://mapstraction.com/svn/mxn > >> > >> > >> > >> -- > >> Andrew Turner > >> mobile: 248.982.3609 > >> andrew at fortiusone.com > >> http://highearthorbit.com > >> > >> http://geocommons.com Helping build the Geospatial Web > >> Introduction to Neogeography - http://oreilly.com/catalog/neogeography > >> _______________________________________________ > >> 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 fortiusone.com > http://highearthorbit.com > > http://geocommons.com Helping build the Geospatial Web > Introduction to Neogeography - http://oreilly.com/catalog/neogeography >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090427/4855ecd1/attachment.htm>
Hi Franz & all, The current implementation isn''t quite in line with that v2 architecture page, it may be that some of the stuff on the page is obsolete due to how the implementation has gone and it may be that it''s just not done yet as it wasn''t needed for "drop 1". Either way I''ll review it and see what''s what. As for the stuff you mention LatLonPoint, Marker, Polyline and significantly integral to the library that they aren''t out on their own. The "toGoogle" type methods are obsolete now and whatever code was in them should instead be in a "toProprietary" method in the .google.js file. Regarding your additional interaction features, I would have said that sounds like application specific code that should probably be a layer on top of mapstraction rather than extensions to it. The improved events system should make doing this much easier - once we''ve sorted out which events we can support and on which objects. Derek On Mon, Apr 27, 2009 at 9:40 AM, Franz Buchinger <fbuchinger at gmail.com>wrote:> Thanks for pointing this out. I really appreciate the new architecture, > because it makes adding new providers much easier and the library itself > much more flexible. > > However it appears that some silent changes to the architecture proposed in > http://mapstraction.com/news/mxn-v2-architecture/ occured: > > - the provider script template doesn''t mention the > LatLonPoint/Marker/Polyline objects that are implemented in your > mxn.google.js script. It is not quite clear which methods have to be > implemented mandatory by a provider plugin. > - $.Module.prototype.toGoogle in the provider template seems to be > obsolete, because now the functional inheritance/extension pattern is used. > And you use toProprietary/fromProprietary methods for converting > mapstraction objects to native provider objects. > > Can/Should I use mapstraction modules to implement additional map > interaction features? E.g. I want a user to interactively draw polygons in a > map, which are composed of polylines and markers. > > Can you please update the preliminary API documentation? > > nice regards, > > Franz > > 2009/4/25 Andrew Turner <ajturner at highearthorbit.com> > > On Fri, Apr 24, 2009 at 4:57 AM, Franz Buchinger <fbuchinger at gmail.com> >> wrote: >> > Hi Andrew, >> > >> > as a recent, but interested follower of mapstraction I''m curious about >> the >> > purpose of this mapstraction branch. >> > >> > Is this basically a more modular mapstraction version (i.e. one .js file >> for >> > each map provider --> you only need to include the providers you want to >> > use)? >> > >> >> Excellent question. >> >> There have been several objectives of the new architecture: >> - modular files: allows a developer to only include providers that will >> be used >> - modular code: developers can focus on code per provider and easier >> to maintain rather than monolithic switch statements >> - tidier code >> >> It''s even better outlined here: >> http://mapstraction.com/news/mxn-v2-architecture/ >> >> For more info - Rob has been adding to the >> http://mapstraction.com/news/ page - so definitely check that out >> >> > Is there any roadmap for further releases? >> >> Not as such yet. Want to first get this release out as soon as >> possible - then we should all definitely brainstorm on what the next >> steps are. >> >> >> > >> > nice regards, >> > >> > Franz >> > >> > 2009/4/24 Andrew Turner <ajturner at highearthorbit.com> >> >> >> >> based on feedback - just rolling with what we have. Move can always >> >> happen later: >> >> >> >> http://mapstraction.com/svn/mxn >> >> >> >> >> >> >> >> -- >> >> Andrew Turner >> >> mobile: 248.982.3609 >> >> andrew at fortiusone.com >> >> http://highearthorbit.com >> >> >> >> http://geocommons.com Helping build the Geospatial Web >> >> Introduction to Neogeography - http://oreilly.com/catalog/neogeography >> >> _______________________________________________ >> >> 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 fortiusone.com >> http://highearthorbit.com >> >> http://geocommons.com Helping build the Geospatial Web >> Introduction to Neogeography - http://oreilly.com/catalog/neogeography >> > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-- Derek Fowler m. 07966 512 369 e. dezfowler at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090427/b0b09ea5/attachment.htm>
Yes, this architecture page is pretty much out of date. Probably worth revisiting once we have this round of code complete :) Rob 2009/4/27 Derek Fowler <dezfowler at gmail.com>> Hi Franz & all, > > The current implementation isn''t quite in line with that v2 architecture > page, it may be that some of the stuff on the page is obsolete due to how > the implementation has gone and it may be that it''s just not done yet as it > wasn''t needed for "drop 1". Either way I''ll review it and see what''s what. > > As for the stuff you mention LatLonPoint, Marker, Polyline and > significantly integral to the library that they aren''t out on their own. The > "toGoogle" type methods are obsolete now and whatever code was in them > should instead be in a "toProprietary" method in the .google.js file. > Regarding your additional interaction features, I would have said that > sounds like application specific code that should probably be a layer on top > of mapstraction rather than extensions to it. The improved events system > should make doing this much easier - once we''ve sorted out which events we > can support and on which objects. > > Derek > > > On Mon, Apr 27, 2009 at 9:40 AM, Franz Buchinger <fbuchinger at gmail.com>wrote: > >> Thanks for pointing this out. I really appreciate the new architecture, >> because it makes adding new providers much easier and the library itself >> much more flexible. >> >> However it appears that some silent changes to the architecture proposed >> in http://mapstraction.com/news/mxn-v2-architecture/ occured: >> >> - the provider script template doesn''t mention the >> LatLonPoint/Marker/Polyline objects that are implemented in your >> mxn.google.js script. It is not quite clear which methods have to be >> implemented mandatory by a provider plugin. >> - $.Module.prototype.toGoogle in the provider template seems to be >> obsolete, because now the functional inheritance/extension pattern is used. >> And you use toProprietary/fromProprietary methods for converting >> mapstraction objects to native provider objects. >> >> Can/Should I use mapstraction modules to implement additional map >> interaction features? E.g. I want a user to interactively draw polygons in a >> map, which are composed of polylines and markers. >> >> Can you please update the preliminary API documentation? >> >> nice regards, >> >> Franz >> >> 2009/4/25 Andrew Turner <ajturner at highearthorbit.com> >> >> On Fri, Apr 24, 2009 at 4:57 AM, Franz Buchinger <fbuchinger at gmail.com> >>> wrote: >>> > Hi Andrew, >>> > >>> > as a recent, but interested follower of mapstraction I''m curious about >>> the >>> > purpose of this mapstraction branch. >>> > >>> > Is this basically a more modular mapstraction version (i.e. one .js >>> file for >>> > each map provider --> you only need to include the providers you want >>> to >>> > use)? >>> > >>> >>> Excellent question. >>> >>> There have been several objectives of the new architecture: >>> - modular files: allows a developer to only include providers that will >>> be used >>> - modular code: developers can focus on code per provider and easier >>> to maintain rather than monolithic switch statements >>> - tidier code >>> >>> It''s even better outlined here: >>> http://mapstraction.com/news/mxn-v2-architecture/ >>> >>> For more info - Rob has been adding to the >>> http://mapstraction.com/news/ page - so definitely check that out >>> >>> > Is there any roadmap for further releases? >>> >>> Not as such yet. Want to first get this release out as soon as >>> possible - then we should all definitely brainstorm on what the next >>> steps are. >>> >>> >>> > >>> > nice regards, >>> > >>> > Franz >>> > >>> > 2009/4/24 Andrew Turner <ajturner at highearthorbit.com> >>> >> >>> >> based on feedback - just rolling with what we have. Move can always >>> >> happen later: >>> >> >>> >> http://mapstraction.com/svn/mxn >>> >> >>> >> >>> >> >>> >> -- >>> >> Andrew Turner >>> >> mobile: 248.982.3609 >>> >> andrew at fortiusone.com >>> >> http://highearthorbit.com >>> >> >>> >> http://geocommons.com Helping build the Geospatial Web >>> >> Introduction to Neogeography - >>> http://oreilly.com/catalog/neogeography >>> >> _______________________________________________ >>> >> 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 fortiusone.com >>> http://highearthorbit.com >>> >>> http://geocommons.com Helping build the Geospatial Web >>> Introduction to Neogeography - http://oreilly.com/catalog/neogeography >>> >> >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> > > > -- > Derek Fowler > m. 07966 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/20090531/c06e0aa8/attachment-0001.htm>