Hi all, I''ve been fiddling with some mapstraction architecture ideas and before I lose my mind (caller, calleee, apply, arguments, pop!), I wanted to share my progress. Please see here for details: http://www.thegecko.org/mapstractionv2/ I''m by no means a javascript guru, so I would appreciate any feedback you may have :) Kind regards, Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090108/0b949bf3/attachment.htm>
Hi guys, I''ve had some time recently to revisit this architecture and have found one or two issues with my proposed approach. The biggest of these is that there is no way that a method call on an object (i.e. Mapstraction.addMarker) can be made to wait until a script is loaded without outlining the entire library structure in the main script library. This means functional modules can''t be loaded on-demand. Provider-specific module implmentations still can, though, as the functional modules can outline the object structure with stubs for each provider-specific method which can wait for scripts to be loaded. The cleanest approach to get round module loading I can see is to specify at ''onLoad'' time what is required. These could be passed as arguments to the main script file. e.g. for mapstraction core module only: <script src=''mapstraction.js''></script> for core and further modules: <script src=''mapstraction.js?modules=geocode,radius,route''></script> This approach loads modules at the beginning rather than on demand ensuring object structures exist. Another minor issues is using prototype with arrays of functions held in an array. For example, if we have the main mapstraction function which required an ''addMarker'' implementation for each provider, the current approach registers these in an array tagged with the provider name. A stub method can invoke these functions as demonstrated in Derek''s example. Problem is, these methods aren''t prototype extensions to the main Mapstraction object so can''t access it''s properties using ''this''. I propose to get around this by using prototype extensions in the provider-specific modules, but to prepend the function names with the providername (e.g. GoogleAddMarker or YahooAddMarker). This is quite dirty in my opinion, but I can''t see a better way to do it. This may all seem vague, but I hope to get another example up in the coming days to show what I mean. hopefully it will actually do some mapping, too! Cheers, Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090120/ac54ba61/attachment.htm>
On Jan 20, 2009, at 9:55 AM, Rob wrote:> Hi guys, > > I''ve had some time recently to revisit this architecture and have > found one or two issues with my proposed approach. > The biggest of these is that there is no way that a method call on > an object (i.e. Mapstraction.addMarker) can be made to wait until a > script is loaded without outlining the entire library structure in > the main script library. > This means functional modules can''t be loaded on-demand. Provider- > specific module implmentations still can, though, as the functional > modules can outline the object structure with stubs for each > provider-specific method which can wait for scripts to be loaded. > The cleanest approach to get round module loading I can see is to > specify at ''onLoad'' time what is required. These could be passed as > arguments to the main script file. > > e.g. > > for mapstraction core module only: > > <script src=''mapstraction.js''></script> > > for core and further modules: > > <script src=''mapstraction.js?modules=geocode,radius,route''></script> > > This approach loads modules at the beginning rather than on demand > ensuring object structures exist.I think it''s acceptable to require that the various modules are explicitly specified. This could be done via the <script> as you''ve outlined, or perhaps by calling a method on the Mapstraction class: Mapstraction.loadModules(["geocode","radius","route"]); ?> > > Another minor issues is using prototype with arrays of functions > held in an array. For example, if we have the main mapstraction > function which required an ''addMarker'' implementation for each > provider, the current approach registers these in an array tagged > with the provider name. > A stub method can invoke these functions as demonstrated in Derek''s > example. Problem is, these methods aren''t prototype extensions to > the main Mapstraction object so can''t access it''s properties using > ''this''. > > I propose to get around this by using prototype extensions in the > provider-specific modules, but to prepend the function names with > the providername (e.g. GoogleAddMarker or YahooAddMarker). This is > quite dirty in my opinion, but I can''t see a better way to do it.Perhaps you can more explicitly explain the problem here. I''m not sure what you mean by "prototype extensions".> > > This may all seem vague, but I hope to get another example up in the > coming days to show what I mean. hopefully it will actually do some > mapping, too!Definitely let us know when you have some more code to check out. Thanks Rob!!> > Cheers, > > Rob > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com-- Andrew Turner mobile: 248.982.3609 email: andrew at highearthorbit.com blog: http://highearthorbit.com -- Helping build the Geospatial Web -- http://geocommons.com --- http://mapufacture.com Introduction to Neogeography - http://oreilly.com/catalog/neogeography
Just realised I didn''t "reply to all" on the first of my replies to Rob so none of the subsequent mails made it to the mailing list. Here they are... ---------- Forwarded message ---------- From: Rob <rob at thegecko.org> Date: Thu, Jan 22, 2009 at 10:05 PM Subject: Re: [Mapstraction] Mapstraction V2 Architecture Demo To: Derek Fowler <dezfowler at gmail.com> Agreed. I seem to have it all working now, so we can see what the overhead is. "apply" worked perfectly, thanks! Watch this space for another demo :) Rob 2009/1/22 Derek Fowler <dezfowler at gmail.com>> I agree the main target of the rewrite should be separating the > provider implementations, I was suggesting that it would be reasonable > for the user to just add script tags for the core and the google bit > of mapstraction in addition to the google api itself. > > If having lazy load in there means a lot of extra code in the core > when size on the wire is a concern then maybe it''s a feature we can do > without. > > Derek > > On 1/22/09, Rob <rob at thegecko.org> wrote: > > Hi Derek, > > > > Thanks for your feedback. > > I have got the on demand loading working and it''s not too dirty. It was > one > > of the requests from Andrew so that only functionality for the preferred > > provider is included, reducing the script footprint. > > > > I agree the module loading isn''t much different to multiple scripts, but > is > > a bit neater as the loading functionality will already be there. > > > > The ''this'' problem is still an issue, so I''ll check out your suggestion. > > > > Cheers, > > > > Rob > > > > 2009/1/22 Derek Fowler <dezfowler at gmail.com> > > > >> Hi Rob, > >> > >> I''m not sure on demand loading would give that much benefit verses the > >> complication it will add to getting it all working. I think that if > >> folks require extra modules they should add extra script tags for them > >> the way they do for other libraries. > >> > >> An advantage of having the whole interface in the core file is that > >> you get code completion in IDEs. > >> > >> As for the "this" issue, you should be able to solve that easily by > >> using a "call" or "apply" when calling the provider specific function. > >> > >> Derek > >> > >> On 1/20/09, Rob <rob at thegecko.org> wrote: > >> > Hi guys, > >> > > >> > I''ve had some time recently to revisit this architecture and have > found > >> one > >> > or two issues with my proposed approach. > >> > The biggest of these is that there is no way that a method call on an > >> object > >> > (i.e. Mapstraction.addMarker) can be made to wait until a script is > >> loaded > >> > without outlining the entire library structure in the main script > >> library. > >> > This means functional modules can''t be loaded on-demand. > >> Provider-specific > >> > module implmentations still can, though, as the functional modules can > >> > outline the object structure with stubs for each provider-specific > >> > method > >> > which can wait for scripts to be loaded. > >> > The cleanest approach to get round module loading I can see is to > >> > specify > >> at > >> > ''onLoad'' time what is required. These could be passed as arguments to > >> > the > >> > main script file. > >> > > >> > e.g. > >> > > >> > for mapstraction core module only: > >> > > >> > <script src=''mapstraction.js''></script> > >> > > >> > for core and further modules: > >> > > >> > <script src=''mapstraction.js?modules=geocode,radius,route''></script> > >> > > >> > This approach loads modules at the beginning rather than on demand > >> ensuring > >> > object structures exist. > >> > > >> > Another minor issues is using prototype with arrays of functions held > >> > in > >> an > >> > array. For example, if we have the main mapstraction function which > >> required > >> > an ''addMarker'' implementation for each provider, the current approach > >> > registers these in an array tagged with the provider name. > >> > A stub method can invoke these functions as demonstrated in Derek''s > >> example. > >> > Problem is, these methods aren''t prototype extensions to the main > >> > Mapstraction object so can''t access it''s properties using ''this''. > >> > > >> > I propose to get around this by using prototype extensions in the > >> > provider-specific modules, but to prepend the function names with the > >> > providername (e.g. GoogleAddMarker or YahooAddMarker). This is quite > >> dirty > >> > in my opinion, but I can''t see a better way to do it. > >> > > >> > This may all seem vague, but I hope to get another example up in the > >> coming > >> > days to show what I mean. hopefully it will actually do some mapping, > >> too! > >> > Cheers, > >> > > >> > Rob > >> > > >> > >> -- > >> Sent from Google Mail for mobile | mobile.google.com > >> > >> Derek Fowler > >> m. 07966 512 369 > >> e. dezfowler at gmail.com > >> > > > > -- > Sent from Google Mail for mobile | mobile.google.com > > Derek Fowler > m. 07966 512 369 > e. dezfowler at gmail.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/20090124/bb115617/attachment.htm>
Just finished 2 more v2 demos which can be found here: http://www.thegecko.org/mapstractionv2/ Demo 3 is the most promising. I''ll post a page on the new blog outlining decisions to be made and design so far. At this stage I think choices are required for naming conventions and module boundaries as this last demo may have the split far too verbose :) Cheers, Rob 2009/1/24 Andrew Turner <andrew at highearthorbit.com>> On Jan 20, 2009, at 9:55 AM, Rob wrote: > > Hi guys, >> >> I''ve had some time recently to revisit this architecture and have found >> one or two issues with my proposed approach. >> The biggest of these is that there is no way that a method call on an >> object (i.e. Mapstraction.addMarker) can be made to wait until a script is >> loaded without outlining the entire library structure in the main script >> library. >> This means functional modules can''t be loaded on-demand. Provider-specific >> module implmentations still can, though, as the functional modules can >> outline the object structure with stubs for each provider-specific method >> which can wait for scripts to be loaded. >> The cleanest approach to get round module loading I can see is to specify >> at ''onLoad'' time what is required. These could be passed as arguments to the >> main script file. >> >> e.g. >> >> for mapstraction core module only: >> >> <script src=''mapstraction.js''></script> >> >> for core and further modules: >> >> <script src=''mapstraction.js?modules=geocode,radius,route''></script> >> >> This approach loads modules at the beginning rather than on demand >> ensuring object structures exist. >> > > I think it''s acceptable to require that the various modules are explicitly > specified. This could be done via the <script> as you''ve outlined, or > perhaps by calling a method on the Mapstraction class: > > Mapstraction.loadModules(["geocode","radius","route"]); ? > > >> >> Another minor issues is using prototype with arrays of functions held in >> an array. For example, if we have the main mapstraction function which >> required an ''addMarker'' implementation for each provider, the current >> approach registers these in an array tagged with the provider name. >> A stub method can invoke these functions as demonstrated in Derek''s >> example. Problem is, these methods aren''t prototype extensions to the main >> Mapstraction object so can''t access it''s properties using ''this''. >> >> I propose to get around this by using prototype extensions in the >> provider-specific modules, but to prepend the function names with the >> providername (e.g. GoogleAddMarker or YahooAddMarker). This is quite dirty >> in my opinion, but I can''t see a better way to do it. >> > > Perhaps you can more explicitly explain the problem here. I''m not sure what > you mean by "prototype extensions". > >> >> >> This may all seem vague, but I hope to get another example up in the >> coming days to show what I mean. hopefully it will actually do some mapping, >> too! >> > > Definitely let us know when you have some more code to check out. Thanks > Rob!! > > >> Cheers, >> >> Rob >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> > > -- > Andrew Turner > mobile: 248.982.3609 > email: andrew at highearthorbit.com > blog: http://highearthorbit.com > > -- Helping build the Geospatial Web -- > http://geocommons.com --- http://mapufacture.com > 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/20090125/149f9991/attachment.htm>
Wow - this is looking *really* great! Curiously, where is the $ method defined? This won''t conflict with Prototype, jQuery, or other JS libraries? On Jan 25, 2009, at 1:07 PM, Rob wrote:> Just finished 2 more v2 demos which can be found here: > > http://www.thegecko.org/mapstractionv2/ > > Demo 3 is the most promising. > I''ll post a page on the new blog outlining decisions to be made and > design so far. > At this stage I think choices are required for naming conventions > and module boundaries as this last demo may have the split far too > verbose :) > > Cheers, > > Rob > > 2009/1/24 Andrew Turner <andrew at highearthorbit.com> > On Jan 20, 2009, at 9:55 AM, Rob wrote: > > Hi guys, > > I''ve had some time recently to revisit this architecture and have > found one or two issues with my proposed approach. > The biggest of these is that there is no way that a method call on > an object (i.e. Mapstraction.addMarker) can be made to wait until a > script is loaded without outlining the entire library structure in > the main script library. > This means functional modules can''t be loaded on-demand. Provider- > specific module implmentations still can, though, as the functional > modules can outline the object structure with stubs for each > provider-specific method which can wait for scripts to be loaded. > The cleanest approach to get round module loading I can see is to > specify at ''onLoad'' time what is required. These could be passed as > arguments to the main script file. > > e.g. > > for mapstraction core module only: > > <script src=''mapstraction.js''></script> > > for core and further modules: > > <script src=''mapstraction.js?modules=geocode,radius,route''></script> > > This approach loads modules at the beginning rather than on demand > ensuring object structures exist. > > I think it''s acceptable to require that the various modules are > explicitly specified. This could be done via the <script> as you''ve > outlined, or perhaps by calling a method on the Mapstraction class: > > Mapstraction.loadModules(["geocode","radius","route"]); ? > > > > > Another minor issues is using prototype with arrays of functions > held in an array. For example, if we have the main mapstraction > function which required an ''addMarker'' implementation for each > provider, the current approach registers these in an array tagged > with the provider name. > A stub method can invoke these functions as demonstrated in Derek''s > example. Problem is, these methods aren''t prototype extensions to > the main Mapstraction object so can''t access it''s properties using > ''this''. > > I propose to get around this by using prototype extensions in the > provider-specific modules, but to prepend the function names with > the providername (e.g. GoogleAddMarker or YahooAddMarker). This is > quite dirty in my opinion, but I can''t see a better way to do it. > > Perhaps you can more explicitly explain the problem here. I''m not > sure what you mean by "prototype extensions". > > > > This may all seem vague, but I hope to get another example up in the > coming days to show what I mean. hopefully it will actually do some > mapping, too! > > Definitely let us know when you have some more code to check out. > Thanks Rob!! > > > Cheers, > > Rob > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > -- > Andrew Turner > mobile: 248.982.3609 > email: andrew at highearthorbit.com > blog: http://highearthorbit.com > > -- Helping build the Geospatial Web -- > http://geocommons.com --- http://mapufacture.com > Introduction to Neogeography - http://oreilly.com/catalog/neogeography > >-- Andrew Turner mobile: 248.982.3609 email: andrew at highearthorbit.com blog: http://highearthorbit.com -- Helping build the Geospatial Web -- http://geocommons.com --- http://mapufacture.com 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/20090125/230304a1/attachment-0001.htm>
It''s a shorthand for the namespace object only defined in scope of the current closure. It''s declared at the bottom of each file :) 2009/1/25 Andrew Turner <andrew at highearthorbit.com>> Wow - this is looking *really* great! > Curiously, where is the $ method defined? This won''t conflict with > Prototype, jQuery, or other JS libraries? > > On Jan 25, 2009, at 1:07 PM, Rob wrote: > > Just finished 2 more v2 demos which can be found here: > http://www.thegecko.org/mapstractionv2/ > > Demo 3 is the most promising. > I''ll post a page on the new blog outlining decisions to be made and design > so far. > At this stage I think choices are required for naming conventions and > module boundaries as this last demo may have the split far too verbose :) > > Cheers, > > Rob > > 2009/1/24 Andrew Turner <andrew at highearthorbit.com> > >> On Jan 20, 2009, at 9:55 AM, Rob wrote: >> >> Hi guys, >>> >>> I''ve had some time recently to revisit this architecture and have found >>> one or two issues with my proposed approach. >>> The biggest of these is that there is no way that a method call on an >>> object (i.e. Mapstraction.addMarker) can be made to wait until a script is >>> loaded without outlining the entire library structure in the main script >>> library. >>> This means functional modules can''t be loaded on-demand. >>> Provider-specific module implmentations still can, though, as the functional >>> modules can outline the object structure with stubs for each >>> provider-specific method which can wait for scripts to be loaded. >>> The cleanest approach to get round module loading I can see is to specify >>> at ''onLoad'' time what is required. These could be passed as arguments to the >>> main script file. >>> >>> e.g. >>> >>> for mapstraction core module only: >>> >>> <script src=''mapstraction.js''></script> >>> >>> for core and further modules: >>> >>> <script src=''mapstraction.js?modules=geocode,radius,route''></script> >>> >>> This approach loads modules at the beginning rather than on demand >>> ensuring object structures exist. >>> >> >> I think it''s acceptable to require that the various modules are explicitly >> specified. This could be done via the <script> as you''ve outlined, or >> perhaps by calling a method on the Mapstraction class: >> >> Mapstraction.loadModules(["geocode","radius","route"]); ? >> >> >>> >>> Another minor issues is using prototype with arrays of functions held in >>> an array. For example, if we have the main mapstraction function which >>> required an ''addMarker'' implementation for each provider, the current >>> approach registers these in an array tagged with the provider name. >>> A stub method can invoke these functions as demonstrated in Derek''s >>> example. Problem is, these methods aren''t prototype extensions to the main >>> Mapstraction object so can''t access it''s properties using ''this''. >>> >>> I propose to get around this by using prototype extensions in the >>> provider-specific modules, but to prepend the function names with the >>> providername (e.g. GoogleAddMarker or YahooAddMarker). This is quite dirty >>> in my opinion, but I can''t see a better way to do it. >>> >> >> Perhaps you can more explicitly explain the problem here. I''m not sure >> what you mean by "prototype extensions". >> >>> >>> >>> This may all seem vague, but I hope to get another example up in the >>> coming days to show what I mean. hopefully it will actually do some mapping, >>> too! >>> >> >> Definitely let us know when you have some more code to check out. Thanks >> Rob!! >> >> >>> Cheers, >>> >>> Rob >>> _______________________________________________ >>> Mapstraction mailing list >>> Mapstraction at lists.mapstraction.com >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >> >> -- >> Andrew Turner >> mobile: 248.982.3609 >> email: andrew at highearthorbit.com >> blog: http://highearthorbit.com >> >> -- Helping build the Geospatial Web -- >> http://geocommons.com --- http://mapufacture.com >> Introduction to Neogeography - http://oreilly.com/catalog/neogeography >> >> > > -- > Andrew Turner > mobile: 248.982.3609 > email: andrew at highearthorbit.com > blog: http://highearthorbit.com > > -- Helping build the Geospatial Web -- > http://geocommons.com --- http://mapufacture.com > 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/20090125/fa69442e/attachment.htm>
Hi Patrickz, we are currently moulding a new architecture for version 2.0 to go forward with. We will then need volunteers to re-implement the providers. We will try to make this as painless as possible. The rewrite will set us up with a more modularised approach allowing easier extension in the future. Plans beyond this are probably better outlined by Andrew, but I''m sure all suggestions are welcome :) Hmm perhaps a feature/voting system if we are inundated with suggestions :) Cheers, Rob 2009/1/26 Patrickz . <patrickz_ at hotmail.com>> Hi guy! > > Can you give us for any plans? > I know Mapstraction are going to new architecture, but we don''t know how > about plan, feature each version or project roadmap. Can you have any news > or update development direction on your blog. > > Regards, > Patrickz > > http://patrickz.developer-labs.com > http://peerasan.blogspot.com > http://gotoknow.org/blog/patrickz > http://www.narisa.com/blog/patrickz > http://forum.asteriskthailand.com > > > > > > ------------------------------ > Date: Sun, 25 Jan 2009 21:38:27 +0000 > From: mapstraction at thegecko.org > To: andrew at highearthorbit.com > CC: mapstraction at lists.mapstraction.com > Subject: Re: [Mapstraction] Mapstraction V2 Architecture Demo > > It''s a shorthand for the namespace object only defined in scope of the > current closure. It''s declared at the bottom of each file :) > > 2009/1/25 Andrew Turner <andrew at highearthorbit.com> > > Wow - this is looking *really* great! > Curiously, where is the $ method defined? This won''t conflict with > Prototype, jQuery, or other JS libraries? > > On Jan 25, 2009, at 1:07 PM, Rob wrote: > > Just finished 2 more v2 demos which can be found here: > http://www.thegecko.org/mapstractionv2/ > > Demo 3 is the most promising. > I''ll post a page on the new blog outlining decisions to be made and design > so far. > At this stage I think choices are required for naming conventions and > module boundaries as this last demo may have the split far too verbose :) > > Cheers, > > Rob > > 2009/1/24 Andrew Turner <andrew at highearthorbit.com> > > On Jan 20, 2009, at 9:55 AM, Rob wrote: > > Hi guys, > > I''ve had some time recently to revisit this architecture and have found one > or two issues with my proposed approach. > The biggest of these is that there is no way that a method call on an > object (i.e. Mapstraction.addMarker) can be made to wait until a script is > loaded without outlining the entire library structure in the main script > library. > This means functional modules can''t be loaded on-demand. Provider-specific > module implmentations still can, though, as the functional modules can > outline the object structure with stubs for each provider-specific method > which can wait for scripts to be loaded. > The cleanest approach to get round module loading I can see is to specify > at ''onLoad'' time what is required. These could be passed as arguments to the > main script file. > > e.g. > > for mapstraction core module only: > > <script src=''mapstraction.js''></script> > > for core and further modules: > > <script src=''mapstraction.js?modules=geocode,radius,route''></script> > > This approach loads modules at the beginning rather than on demand ensuring > object structures exist. > > > I think it''s acceptable to require that the various modules are explicitly > specified. This could be done via the <script> as you''ve outlined, or > perhaps by calling a method on the Mapstraction class: > > Mapstraction.loadModules(["geocode","radius","route"]); ? > > > > Another minor issues is using prototype with arrays of functions held in an > array. For example, if we have the main mapstraction function which required > an ''addMarker'' implementation for each provider, the current approach > registers these in an array tagged with the provider name. > A stub method can invoke these functions as demonstrated in Derek''s > example. Problem is, these methods aren''t prototype extensions to the main > Mapstraction object so can''t access it''s properties using ''this''. > > I propose to get around this by using prototype extensions in the > provider-specific modules, but to prepend the function names with the > providername (e.g. GoogleAddMarker or YahooAddMarker). This is quite dirty > in my opinion, but I can''t see a better way to do it. > > > Perhaps you can more explicitly explain the problem here. I''m not sure what > you mean by "prototype extensions". > > > > This may all seem vague, but I hope to get another example up in the coming > days to show what I mean. hopefully it will actually do some mapping, too! > > > Definitely let us know when you have some more code to check out. Thanks > Rob!! > > > Cheers, > > Rob > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > -- > Andrew Turner > mobile: 248.982.3609 > email: andrew at highearthorbit.com > blog: http://highearthorbit.com > > -- Helping build the Geospatial Web -- > http://geocommons.com --- http://mapufacture.com > Introduction to Neogeography - http://oreilly.com/catalog/neogeography > > > > -- > Andrew Turner > mobile: 248.982.3609 > email: andrew at highearthorbit.com > blog: http://highearthorbit.com > > -- Helping build the Geospatial Web -- > http://geocommons.com --- http://mapufacture.com > Introduction to Neogeography - http://oreilly.com/catalog/neogeography > > > > ------------------------------ > Get news, entertainment and everything you care about at Live.com. Check > it out! <http://www.live.com/getstarted.aspx> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20090126/143c76d0/attachment.htm>
On Jan 26, 2009, at 4:12 AM, Rob wrote:> Hi Patrickz, > > we are currently moulding a new architecture for version 2.0 to go > forward with. We will then need volunteers to re-implement the > providers. We will try to make this as painless as possible. > The rewrite will set us up with a more modularised approach allowing > easier extension in the future. > > Plans beyond this are probably better outlined by Andrew, but I''m > sure all suggestions are welcome :) > > Hmm perhaps a feature/voting system if we are inundated with > suggestions :)Interesting ideas - and with the rearch a good time to reorganize and get people ''signed up'' to support a provider or two, and lay out future features/capabilities - though obviously with any open-source software, "out of the blue" patches are typically welcome. The first is just getting a clean base, documentation, tutorials/ howtos, and building & connecting the existing community. I''ll clean up the Trac instance for actual tickets and features.> > Cheers, > > Rob > > 2009/1/26 Patrickz . <patrickz_ at hotmail.com> > Hi guy! > > Can you give us for any plans? > I know Mapstraction are going to new architecture, but we don''t know > how about plan, feature each version or project roadmap. Can you > have any news or update development direction on your blog. > > Regards, > Patrickz > > http://patrickz.developer-labs.com > http://peerasan.blogspot.com > http://gotoknow.org/blog/patrickz > http://www.narisa.com/blog/patrickz > http://forum.asteriskthailand.com > > > > > > Date: Sun, 25 Jan 2009 21:38:27 +0000 > From: mapstraction at thegecko.org > To: andrew at highearthorbit.com > CC: mapstraction at lists.mapstraction.com > > Subject: Re: [Mapstraction] Mapstraction V2 Architecture Demo > > It''s a shorthand for the namespace object only defined in scope of > the current closure. It''s declared at the bottom of each file :) > > 2009/1/25 Andrew Turner <andrew at highearthorbit.com> > Wow - this is looking *really* great! > > Curiously, where is the $ method defined? This won''t conflict with > Prototype, jQuery, or other JS libraries? > > On Jan 25, 2009, at 1:07 PM, Rob wrote: > > Just finished 2 more v2 demos which can be found here: > > http://www.thegecko.org/mapstractionv2/ > > Demo 3 is the most promising. > I''ll post a page on the new blog outlining decisions to be made and > design so far. > At this stage I think choices are required for naming conventions > and module boundaries as this last demo may have the split far too > verbose :) > > Cheers, > > Rob > > 2009/1/24 Andrew Turner <andrew at highearthorbit.com> > On Jan 20, 2009, at 9:55 AM, Rob wrote: > > Hi guys, > > I''ve had some time recently to revisit this architecture and have > found one or two issues with my proposed approach. > The biggest of these is that there is no way that a method call on > an object (i.e. Mapstraction.addMarker) can be made to wait until a > script is loaded without outlining the entire library structure in > the main script library. > This means functional modules can''t be loaded on-demand. Provider- > specific module implmentations still can, though, as the functional > modules can outline the object structure with stubs for each > provider-specific method which can wait for scripts to be loaded. > The cleanest approach to get round module loading I can see is to > specify at ''onLoad'' time what is required. These could be passed as > arguments to the main script file. > > e.g. > > for mapstraction core module only: > > <script src=''mapstraction.js''></script> > > for core and further modules: > > <script src=''mapstraction.js?modules=geocode,radius,route''></script> > > This approach loads modules at the beginning rather than on demand > ensuring object structures exist. > > I think it''s acceptable to require that the various modules are > explicitly specified. This could be done via the <script> as you''ve > outlined, or perhaps by calling a method on the Mapstraction class: > > Mapstraction.loadModules(["geocode","radius","route"]); ? > > > > > Another minor issues is using prototype with arrays of functions > held in an array. For example, if we have the main mapstraction > function which required an ''addMarker'' implementation for each > provider, the current approach registers these in an array tagged > with the provider name. > A stub method can invoke these functions as demonstrated in Derek''s > example. Problem is, these methods aren''t prototype extensions to > the main Mapstraction object so can''t access it''s properties using > ''this''. > > I propose to get around this by using prototype extensions in the > provider-specific modules, but to prepend the function names with > the providername (e.g. GoogleAddMarker or YahooAddMarker). This is > quite dirty in my opinion, but I can''t see a better way to do it. > > Perhaps you can more explicitly explain the problem here. I''m not > sure what you mean by "prototype extensions". > > > > This may all seem vague, but I hope to get another example up in the > coming days to show what I mean. hopefully it will actually do some > mapping, too! > > Definitely let us know when you have some more code to check out. > Thanks Rob!! > > > Cheers, > > Rob > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > -- > Andrew Turner > mobile: 248.982.3609 > email: andrew at highearthorbit.com > blog: http://highearthorbit.com > > -- Helping build the Geospatial Web -- > http://geocommons.com --- http://mapufacture.com > Introduction to Neogeography - http://oreilly.com/catalog/neogeography > > > > -- > Andrew Turner > mobile: 248.982.3609 > email: andrew at highearthorbit.com > blog: http://highearthorbit.com > > -- Helping build the Geospatial Web -- > http://geocommons.com --- http://mapufacture.com > Introduction to Neogeography - http://oreilly.com/catalog/neogeography > > > > Get news, entertainment and everything you care about at Live.com. > Check it out! > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com-- Andrew Turner mobile: 248.982.3609 email: andrew at highearthorbit.com blog: http://highearthorbit.com -- Helping build the Geospatial Web -- http://geocommons.com --- http://mapufacture.com 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/20090126/17cb4e67/attachment-0001.htm>
I''d agree the splits are too verbose at the moment - I think we need
the
"core" stuff in one file like markers and the less used bits (whatever
they
are) in separate files.
I''m not sure about using $, although it is in a closure have you
checked
what the effects are if you have a globally defined $ variable already -
does it just hide the global one or do you get a JavaScript error? Either
way I''d prefer steering well clear of $ to avoid confusion for folks
coming
to Mapstraction and thinking it uses jQuery somewhere.
We could also do with making the provider specific bits as concise and
readable as possible. There seems to be quite a lot of repeated code in your
current example. I also like the idea of the definition of the provider
functions being within the registerProvider call, something like...
mxn.registerProvider(''google'', {
addMarker: function(){
},
...
});
That way we can have a blank version of this with all the functions empty
and folks can just fill in the provider ID and all the function bodies.
Requiring additional modules could be an override of the registerProvider()
function that just take another argument.
Derek
On Sun, Jan 25, 2009 at 6:07 PM, Rob <mapstraction at thegecko.org> wrote:
> Just finished 2 more v2 demos which can be found here:
> http://www.thegecko.org/mapstractionv2/
>
> Demo 3 is the most promising.
> I''ll post a page on the new blog outlining decisions to be made
and design
> so far.
> At this stage I think choices are required for naming conventions and
> module boundaries as this last demo may have the split far too verbose :)
>
> Cheers,
>
> Rob
>
> 2009/1/24 Andrew Turner <andrew at highearthorbit.com>
>
> On Jan 20, 2009, at 9:55 AM, Rob wrote:
>>
>> Hi guys,
>>>
>>> I''ve had some time recently to revisit this architecture
and have found
>>> one or two issues with my proposed approach.
>>> The biggest of these is that there is no way that a method call on
an
>>> object (i.e. Mapstraction.addMarker) can be made to wait until a
script is
>>> loaded without outlining the entire library structure in the main
script
>>> library.
>>> This means functional modules can''t be loaded on-demand.
>>> Provider-specific module implmentations still can, though, as the
functional
>>> modules can outline the object structure with stubs for each
>>> provider-specific method which can wait for scripts to be loaded.
>>> The cleanest approach to get round module loading I can see is to
specify
>>> at ''onLoad'' time what is required. These could be
passed as arguments to the
>>> main script file.
>>>
>>> e.g.
>>>
>>> for mapstraction core module only:
>>>
>>> <script
src=''mapstraction.js''></script>
>>>
>>> for core and further modules:
>>>
>>> <script
src=''mapstraction.js?modules=geocode,radius,route''></script>
>>>
>>> This approach loads modules at the beginning rather than on demand
>>> ensuring object structures exist.
>>>
>>
>> I think it''s acceptable to require that the various modules
are explicitly
>> specified. This could be done via the <script> as you''ve
outlined, or
>> perhaps by calling a method on the Mapstraction class:
>>
>>
Mapstraction.loadModules(["geocode","radius","route"]);
?
>>
>>
>>>
>>> Another minor issues is using prototype with arrays of functions
held in
>>> an array. For example, if we have the main mapstraction function
which
>>> required an ''addMarker'' implementation for each
provider, the current
>>> approach registers these in an array tagged with the provider name.
>>> A stub method can invoke these functions as demonstrated in
Derek''s
>>> example. Problem is, these methods aren''t prototype
extensions to the main
>>> Mapstraction object so can''t access it''s
properties using ''this''.
>>>
>>> I propose to get around this by using prototype extensions in the
>>> provider-specific modules, but to prepend the function names with
the
>>> providername (e.g. GoogleAddMarker or YahooAddMarker). This is
quite dirty
>>> in my opinion, but I can''t see a better way to do it.
>>>
>>
>> Perhaps you can more explicitly explain the problem here. I''m
not sure
>> what you mean by "prototype extensions".
>>
>>>
>>>
>>> This may all seem vague, but I hope to get another example up in
the
>>> coming days to show what I mean. hopefully it will actually do some
mapping,
>>> too!
>>>
>>
>> Definitely let us know when you have some more code to check out.
Thanks
>> Rob!!
>>
>>
>>> Cheers,
>>>
>>> Rob
>>> _______________________________________________
>>> Mapstraction mailing list
>>> Mapstraction at lists.mapstraction.com
>>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>>
>>
>> --
>> Andrew Turner
>> mobile: 248.982.3609
>> email: andrew at highearthorbit.com
>> blog: http://highearthorbit.com
>>
>> -- Helping build the Geospatial Web --
>> http://geocommons.com --- http://mapufacture.com
>> 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/20090127/ca876bc5/attachment.htm>
Comments below :) Cheers, Rob 2009/1/27 Derek Fowler <dezfowler at gmail.com>> I''d agree the splits are too verbose at the moment - I think we need the > "core" stuff in one file like markers and the less used bits (whatever they > are) in separate files.These boundaries just need to be defined, the verbose split was to help test the demo.> > > I''m not sure about using $, although it is in a closure have you checked > what the effects are if you have a globally defined $ variable already - > does it just hide the global one or do you get a JavaScript error? Either > way I''d prefer steering well clear of $ to avoid confusion for folks coming > to Mapstraction and thinking it uses jQuery somewhere.Shouldn''t be a problem, but I can see the confusion with jQuery. Perhaps use a different shirtcut like $m?> > > We could also do with making the provider specific bits as concise and > readable as possible. There seems to be quite a lot of repeated code in your > current example.Could you outline where these are? the ''require'' functions in each file are optional if other scripts are not required.> I also like the idea of the definition of the provider functions being > within the registerProvider call, something like... > > mxn.registerProvider(''google'', { > > addMarker: function(){ > > }, > > ... > > }); >The reason I didn''t do it this way is that it''s very easy to get lost with {}''s and commas breaking the code. Especially with the mapstraction module as it''s so large. Concisely pulling out functions to register means private functions don''t get exposed. Your suggestion above also doesn''t seem to allow for direct extensions to objects. e.g. mxn.LatLonPoint.prototype.toGoogle = function {....};> > That way we can have a blank version of this with all the functions empty > and folks can just fill in the provider ID and all the function bodies.This was one of my intentions and either design will facilitate this :)> > > Requiring additional modules could be an override of the registerProvider() > function that just take another argument.Yes, that would work, although may need to be passed as first argument to avoid having a null passed when a module requires provider loading and no modules: registerModules(bool loadProviders, array Modules); BoundingBox - registerModules(false, ''mapstraction''); Mapstraction - registerModules(true);> > Derek > > > On Sun, Jan 25, 2009 at 6:07 PM, Rob <mapstraction at thegecko.org> wrote: > >> Just finished 2 more v2 demos which can be found here: >> http://www.thegecko.org/mapstractionv2/ >> >> Demo 3 is the most promising. >> I''ll post a page on the new blog outlining decisions to be made and design >> so far. >> At this stage I think choices are required for naming conventions and >> module boundaries as this last demo may have the split far too verbose :) >> >> Cheers, >> >> Rob >> >> 2009/1/24 Andrew Turner <andrew at highearthorbit.com> >> >> On Jan 20, 2009, at 9:55 AM, Rob wrote: >>> >>> Hi guys, >>>> >>>> I''ve had some time recently to revisit this architecture and have found >>>> one or two issues with my proposed approach. >>>> The biggest of these is that there is no way that a method call on an >>>> object (i.e. Mapstraction.addMarker) can be made to wait until a script is >>>> loaded without outlining the entire library structure in the main script >>>> library. >>>> This means functional modules can''t be loaded on-demand. >>>> Provider-specific module implmentations still can, though, as the functional >>>> modules can outline the object structure with stubs for each >>>> provider-specific method which can wait for scripts to be loaded. >>>> The cleanest approach to get round module loading I can see is to >>>> specify at ''onLoad'' time what is required. These could be passed as >>>> arguments to the main script file. >>>> >>>> e.g. >>>> >>>> for mapstraction core module only: >>>> >>>> <script src=''mapstraction.js''></script> >>>> >>>> for core and further modules: >>>> >>>> <script src=''mapstraction.js?modules=geocode,radius,route''></script> >>>> >>>> This approach loads modules at the beginning rather than on demand >>>> ensuring object structures exist. >>>> >>> >>> I think it''s acceptable to require that the various modules are >>> explicitly specified. This could be done via the <script> as you''ve >>> outlined, or perhaps by calling a method on the Mapstraction class: >>> >>> Mapstraction.loadModules(["geocode","radius","route"]); ? >>> >>> >>>> >>>> Another minor issues is using prototype with arrays of functions held in >>>> an array. For example, if we have the main mapstraction function which >>>> required an ''addMarker'' implementation for each provider, the current >>>> approach registers these in an array tagged with the provider name. >>>> A stub method can invoke these functions as demonstrated in Derek''s >>>> example. Problem is, these methods aren''t prototype extensions to the main >>>> Mapstraction object so can''t access it''s properties using ''this''. >>>> >>>> I propose to get around this by using prototype extensions in the >>>> provider-specific modules, but to prepend the function names with the >>>> providername (e.g. GoogleAddMarker or YahooAddMarker). This is quite dirty >>>> in my opinion, but I can''t see a better way to do it. >>>> >>> >>> Perhaps you can more explicitly explain the problem here. I''m not sure >>> what you mean by "prototype extensions". >>> >>>> >>>> >>>> This may all seem vague, but I hope to get another example up in the >>>> coming days to show what I mean. hopefully it will actually do some mapping, >>>> too! >>>> >>> >>> Definitely let us know when you have some more code to check out. Thanks >>> Rob!! >>> >>> >>>> Cheers, >>>> >>>> Rob >>>> _______________________________________________ >>>> Mapstraction mailing list >>>> Mapstraction at lists.mapstraction.com >>>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>>> >>> >>> -- >>> Andrew Turner >>> mobile: 248.982.3609 >>> email: andrew at highearthorbit.com >>> blog: http://highearthorbit.com >>> >>> -- Helping build the Geospatial Web -- >>> http://geocommons.com --- http://mapufacture.com >>> 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/20090127/ea4ecaa2/attachment-0001.htm>
On Jan 27, 2009, at 4:56 AM, Rob wrote:> Comments below :) > > Cheers, > > Rob > > 2009/1/27 Derek Fowler <dezfowler at gmail.com> > I''d agree the splits are too verbose at the moment - I think we need > the "core" stuff in one file like markers and the less used bits > (whatever they are) in separate files. > > > These boundaries just need to be defined, the verbose split was to > help test the demo.Here is a rough dump and coverage of the functions: http://mapstraction.com/features.php This matrix doesn''t go into routing/geocoding, but those are clearly different modules. Is there a reason that we wouldn''t include just about everything in this matrix (which is mapstraction.js) in the core module? One ''module'' that I could see splitting out would be Filtering. As it''s implemented in Mapstraction it is primarily not provider specific but just helper functions. So perhaps a general Marker Manager (ala GMaps of the similar name). This could then implement filtering, clustering, thematics, etc. Another could be any overlays: Tile, JSON, Image; into a module.> > > > I''m not sure about using $, although it is in a closure have you > checked what the effects are if you have a globally defined $ > variable already - does it just hide the global one or do you get a > JavaScript error? Either way I''d prefer steering well clear of $ to > avoid confusion for folks coming to Mapstraction and thinking it > uses jQuery somewhere. > > > Shouldn''t be a problem, but I can see the confusion with jQuery. > Perhaps use a different shirtcut like $m?Yes, $m is better and has been used already before in Mapstraction.> > > > We could also do with making the provider specific bits as concise > and readable as possible. There seems to be quite a lot of repeated > code in your current example. > > Could you outline where these are? the ''require'' functions in each > file are optional if other scripts are not required.I agree this is one of the primary objectives of this re-architecting, though I''m not beholden to one method or the other on how to achieve this. So long as there is: a blank template, clear mechanism for how to extend, potentially a way to query the provider to see what methods are implemented.> > > I also like the idea of the definition of the provider functions > being within the registerProvider call, something like... > > mxn.registerProvider(''google'', { > > addMarker: function(){ > > }, > > ... > > }); > > The reason I didn''t do it this way is that it''s very easy to get > lost with {}''s and commas breaking the code. Especially with the > mapstraction module as it''s so large. Concisely pulling out > functions to register means private functions don''t get exposed. > Your suggestion above also doesn''t seem to allow for direct > extensions to objects. > > e.g. mxn.LatLonPoint.prototype.toGoogle = function {....}; > > > That way we can have a blank version of this with all the functions > empty and folks can just fill in the provider ID and all the > function bodies. > > > This was one of my intentions and either design will facilitate > this :) > > > Requiring additional modules could be an override of the > registerProvider() function that just take another argument. > > Yes, that would work, although may need to be passed as first > argument to avoid having a null passed when a module requires > provider loading and no modules: > > registerModules(bool loadProviders, array Modules); > > BoundingBox - registerModules(false, ''mapstraction''); > Mapstraction - registerModules(true); > > > > Derek > > > On Sun, Jan 25, 2009 at 6:07 PM, Rob <mapstraction at thegecko.org> > wrote: > Just finished 2 more v2 demos which can be found here: > > http://www.thegecko.org/mapstractionv2/ > > Demo 3 is the most promising. > I''ll post a page on the new blog outlining decisions to be made and > design so far. > At this stage I think choices are required for naming conventions > and module boundaries as this last demo may have the split far too > verbose :) > > Cheers, > > Rob > > 2009/1/24 Andrew Turner <andrew at highearthorbit.com> > > On Jan 20, 2009, at 9:55 AM, Rob wrote: > > Hi guys, > > I''ve had some time recently to revisit this architecture and have > found one or two issues with my proposed approach. > The biggest of these is that there is no way that a method call on > an object (i.e. Mapstraction.addMarker) can be made to wait until a > script is loaded without outlining the entire library structure in > the main script library. > This means functional modules can''t be loaded on-demand. Provider- > specific module implmentations still can, though, as the functional > modules can outline the object structure with stubs for each > provider-specific method which can wait for scripts to be loaded. > The cleanest approach to get round module loading I can see is to > specify at ''onLoad'' time what is required. These could be passed as > arguments to the main script file. > > e.g. > > for mapstraction core module only: > > <script src=''mapstraction.js''></script> > > for core and further modules: > > <script src=''mapstraction.js?modules=geocode,radius,route''></script> > > This approach loads modules at the beginning rather than on demand > ensuring object structures exist. > > I think it''s acceptable to require that the various modules are > explicitly specified. This could be done via the <script> as you''ve > outlined, or perhaps by calling a method on the Mapstraction class: > > Mapstraction.loadModules(["geocode","radius","route"]); ? > > > > > Another minor issues is using prototype with arrays of functions > held in an array. For example, if we have the main mapstraction > function which required an ''addMarker'' implementation for each > provider, the current approach registers these in an array tagged > with the provider name. > A stub method can invoke these functions as demonstrated in Derek''s > example. Problem is, these methods aren''t prototype extensions to > the main Mapstraction object so can''t access it''s properties using > ''this''. > > I propose to get around this by using prototype extensions in the > provider-specific modules, but to prepend the function names with > the providername (e.g. GoogleAddMarker or YahooAddMarker). This is > quite dirty in my opinion, but I can''t see a better way to do it. > > Perhaps you can more explicitly explain the problem here. I''m not > sure what you mean by "prototype extensions". > > > > This may all seem vague, but I hope to get another example up in the > coming days to show what I mean. hopefully it will actually do some > mapping, too! > > Definitely let us know when you have some more code to check out. > Thanks Rob!! > > > Cheers, > > Rob > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > -- > Andrew Turner > mobile: 248.982.3609 > email: andrew at highearthorbit.com > blog: http://highearthorbit.com > > -- Helping build the Geospatial Web -- > http://geocommons.com --- http://mapufacture.com > 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 >-- Andrew Turner mobile: 248.982.3609 email: andrew at highearthorbit.com blog: http://highearthorbit.com -- Helping build the Geospatial Web -- http://geocommons.com --- http://mapufacture.com 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/20090127/cc913c86/attachment.htm>
This may be a silly question, but can someone point me to something that provides background information on V2? What are the benefits and will it be backwards compatible? --- Adam DuVander I like simple: http://adamduvander.com
Hi Adam, When the new blog is launched it will have this information on a page on it. Cheers, Rob Rob Moran Development Manager Opportunity Links Trust Court, The Vision Park, Histon, Cambridge CB24 9PW Tel 01223 566 522 Fax 01223 500 281 Web www.opp-links.org.uk Opportunity Links Ltd is registered in England 3565647. VAT 784 9533 75 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 Adam DuVander Sent: 28 January 2009 00:01 To: mapstraction at lists.mapstraction.com Subject: Re: [Mapstraction] Mapstraction V2 Architecture Demo This may be a silly question, but can someone point me to something that provides background information on V2? What are the benefits and will it be backwards compatible? --- Adam DuVander I like simple: http://adamduvander.com _______________________________________________ Mapstraction mailing list Mapstraction at lists.mapstraction.com http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
Adam DuVander wrote on Jan 27, 2009, at 7:00 PM,> This may be a silly question, but can someone point me to something > that provides background information on V2? What are the benefits > and will it be backwards compatible?As Rob said - we''ll start documenting this more on the /news blog. For quick answers, it will be backwards compatible (i.e. perhaps just update the JS that is being pointed to). The changes provide: - small file size, for faster download of the JS files - smaller memory footprint (assumedly, will need testing) - faster loading and operation overall - easier maintainability - easier extensibility - everyone gets a Goldfish (maybe) Andrew
Hi folks, As promised - the demo''s now working... http://dfowler.geeksbox.co.uk/demos/mapstraction-2/latest/index.htm No script auto loading yet but I got two of the new events working to give you an idea of them. Haven''t got much code coverage in those tests so I''ll try and get a few more in for the next demo as well as improving the commenting. Any thoughts - let me know. Derek -- 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/20090218/6c8e42a8/attachment.htm>
Hehe, showoff :) I love the unit testing approach! I''ll check out the code a bit later. Cheers, Rob 2009/2/18 Derek Fowler <dezfowler at gmail.com>> Hi folks, > As promised - the demo''s now working... > > http://dfowler.geeksbox.co.uk/demos/mapstraction-2/latest/index.htm > > No script auto loading yet but I got two of the new events working to give > you an idea of them. > > Haven''t got much code coverage in those tests so I''ll try and get a few > more in for the next demo as well as improving the commenting. > > Any thoughts - let me know. > > Derek > > -- > 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/20090218/9a4d90d8/attachment.htm>
How are things progressing with mxn2? Are we at a stage to begin implementing this and getting it into SVN? Cheers, Rob 2009/2/18 Derek Fowler <dezfowler at gmail.com>> Hi folks, > As promised - the demo''s now working... > > http://dfowler.geeksbox.co.uk/demos/mapstraction-2/latest/index.htm > > No script auto loading yet but I got two of the new events working to give > you an idea of them. > > Haven''t got much code coverage in those tests so I''ll try and get a few > more in for the next demo as well as improving the commenting. > > Any thoughts - let me know. > > Derek > > -- > 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/20090308/b5792583/attachment.htm>
Hmm distributed source control. Wary, but I''d love to give it a go :) I''ve setup a repo on github.com, but it seems to be tied to my username: git://github.com/thegecko/mapstraction.git perhaps create a user called mxn and hang repos off that? I''m not up on git, so may be missing something :) Rob 2009/3/8 Andrew Turner <ajturner at gmail.com>> Rob wrote: > > How are things progressing with mxn2? Are we at a stage to begin > implementing this and getting it into SVN? > > Indeed - great question. > > Also, what are your thoughts on putting it into Github for actual code > hosting? I''m quite in love with the whole branching/merging capabilities of > git. It would help promote the project, and can still host examples, etc. on > the mapstraction.com site. > > > Cheers, > > Rob > > 2009/2/18 Derek Fowler <dezfowler at gmail.com> > >> Hi folks, >> As promised - the demo''s now working... >> >> http://dfowler.geeksbox.co.uk/demos/mapstraction-2/latest/index.htm >> >> No script auto loading yet but I got two of the new events working to >> give you an idea of them. >> >> Haven''t got much code coverage in those tests so I''ll try and get a few >> more in for the next demo as well as improving the commenting. >> >> Any thoughts - let me know. >> >> Derek >> >> -- >> 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 > > > ------------------------------ > > _______________________________________________ > Mapstraction mailing listMapstraction at lists.mapstraction.comhttp://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > > -- > Andrew Turner > mobile: 248.982.3609 > email: andrew at highearthorbit.com > blog: http://highearthorbit.com > > -- Helping build the Geospatial Web --http://geocommons.com --- http://mapufacture.com > 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/20090308/28d2e20d/attachment.htm>
Rob wrote:> Hmm distributed source control. Wary, but I''d love to give it a go :) > I''ve setup a repo on github.com <http://github.com>, but it seems to > be tied to my username: > > git://github.com/thegecko/mapstraction.git > > perhaps create a user called mxn and hang repos off that? I''m not up > on git, so may be missing something :) >The point of Git is that it''s decentralized. Anyone can make a branch (which in something like github *does* make it difficult to have a canonical master to always go back to) I created a http://github.com/mapstraction - just to be explicit.> Rob > > 2009/3/8 Andrew Turner <ajturner at gmail.com <mailto:ajturner at gmail.com>> > > Rob wrote: >> How are things progressing with mxn2? Are we at a stage to begin >> implementing this and getting it into SVN? >> > Indeed - great question. > > Also, what are your thoughts on putting it into Github for actual > code hosting? I''m quite in love with the whole branching/merging > capabilities of git. It would help promote the project, and can > still host examples, etc. on the mapstraction.com > <http://mapstraction.com> site. > > >> Cheers, >> >> Rob >> >> 2009/2/18 Derek Fowler <dezfowler at gmail.com >> <mailto:dezfowler at gmail.com>> >> >> Hi folks, >> >> As promised - the demo''s now working... >> >> http://dfowler.geeksbox.co.uk/demos/mapstraction-2/latest/index.htm >> >> No script auto loading yet but I got two of the new events >> working to give you an idea of them. >> >> Haven''t got much code coverage in those tests so I''ll try and >> get a few more in for the next demo as well as improving the >> commenting. >> >> Any thoughts - let me know. >> >> Derek >> >> -- >> Derek Fowler >> m. 07966 512 369 >> e. dezfowler at gmail.com <mailto:dezfowler at gmail.com> >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> <mailto:Mapstraction at lists.mapstraction.com> >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> >> ------------------------------------------------------------------------ >> _______________________________________________ Mapstraction >> mailing list Mapstraction at lists.mapstraction.com >> <mailto:Mapstraction at lists.mapstraction.com> >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> > > > -- > Andrew Turner > mobile: 248.982.3609 > email:andrew at highearthorbit.com <mailto:andrew at highearthorbit.com> > blog:http://highearthorbit.com > > -- Helping build the Geospatial Web -- > http://geocommons.com ---http://mapufacture.com > Introduction to Neogeography -http://oreilly.com/catalog/neogeography >-- Andrew Turner mobile: 248.982.3609 email: andrew at highearthorbit.com blog: http://highearthorbit.com -- Helping build the Geospatial Web -- http://geocommons.com --- http://mapufacture.com 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/20090308/f1afa485/attachment-0001.htm>
I''ve had to work the last couple of weekends unfortunately so I haven''t been able to make any real progress. I''m going to try and get it to a good stage this week so reply to this thread with any comments you have on the demo and I''ll try and get them seen to. I''m not familiar with github but whatever you guys think is best. Derek On Sun, Mar 8, 2009 at 4:38 PM, Rob <mapstraction at thegecko.org> wrote:> How are things progressing with mxn2? Are we at a stage to begin > implementing this and getting it into SVN? > Cheers, > > Rob > > 2009/2/18 Derek Fowler <dezfowler at gmail.com> > >> Hi folks, >> >> As promised - the demo''s now working... >> >> http://dfowler.geeksbox.co.uk/demos/mapstraction-2/latest/index.htm >> >> No script auto loading yet but I got two of the new events working to give >> you an idea of them. >> >> Haven''t got much code coverage in those tests so I''ll try and get a few >> more in for the next demo as well as improving the commenting. >> >> Any thoughts - let me know. >> >> Derek >> >> -- >> 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 >> >> >-- 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/20090308/0273a90f/attachment.htm>