[geojquery] Re: geojuery core design

Volker Mische volker.mische at gmail.com
Tue Mar 16 03:02:27 EDT 2010


I'll use my own thread for further ideas. I will use it to document a
bit of my findings and as a chance for other people to shout at me if
they hate it (or perhaps even like it).

Tonight I've coded a bit with the $.map() approach. So far it seems
alright, but I've bumped to another essential question. It's about
chaining and changing the scope. Should we have many different scopes
(e.g. for map, layer, features) or as less as possible (perhaps even
only map?). I'll illustrate it with layers. I thought about the
following API:

To create a new layer:
var mymap = $.map($('#map', options).layer('some_layer_id', {
    'label': 'foo',
    'type': 'WMS',
    'url': 'http://example.com',
    ...})

To access it:
mymap.layer('some_layer_id');

No you could get features e.g. with:
mymap.layer('some_layer_id').features(i_might_want_a_filter_in_here);

So the scope will be changed from map, to layers and even further to
features (e.g. if you add a click event to fatures). I like that idea
(btw: jQuery does comparable things when you use things like
"children()" as well and it feels quite natural). But there's also a
problem with it. If you want to remove a layer, is it associated with
the map or not? I mean:
mymap.removeLayer('some_layer_id') vs. mymap.layer('some_layer_id').remove()

The first way would programatically be easier, the second probably
nicer. Another problem with changing the scope is that you need a way to
get back to the original one. For example if you want to add multiple
layers,
mymap.layer('id1', {}).layer('id2', {}) won't work, you would need
something along the lines of:
mymap.layer('id1', {}).map().layer('id2', {});
Or you delegate a layer() call automatically to the map if it's called
from the layers scope.

Therefore here's a way to get the features without changing the scope:
mymap.features('some_layer_id, i_might_want_a_filter_in_here);
As a bonus you would obviously use mymap.removeLayer('some_layer_id').

I hope that at least part of what I'm saying was understandable, it's
again already pretty late here :)

Cheers,
  Volker

Volker Mische wrote:
> Hi,
> 
> tonight I hacked a bit on how geojquery core could look like. It's not
> as easy as I've thought it would be. Here's my conclusion, the reasoning
> follows.
> 
> I suggest that we create an jQuery-ish API around OpenLayers. This means
> it is not really tightly connected with jQuery's DOM manipulation, but
> with jQuery's design ideas about being simple and the chainability (kind
> of).
> 
> For not polluting the global or jQuery namespace there will be a single
> entry point: $.map() (or $.geo(), $.geojquery(), $.whatever()). It will
> have a jQuery object as parameter and probably some initial options:
> $.map($('#mymap'), {mymapoptions}
> 
> Than you can use functions like .wfs(), .layers(), .vector(),
> .whateverwecomeupwith() on it. And there will be a jq() method that
> returns an jQuery object. This way you can manipulate your map with pure
> jQuery after you've created that map, e.g. for resizing.
> 
> Now to the reasoning. I know that this sounds ugly. $('#mymap').map()
> looks so much nicer. But as I return a new map object, the old jQuery
> functions won't be there. In case e.g. the jQuery selector doesn't match
> anything, it will just break, as with map() the jQuery chain is broken
> (one could return the original jQuery object in such cases, but if any
> other geojquery function follows the map() it will break anyway).
> 
> We clearly operate on a map, not on DOM anymore, this should also be
> visible to the user of geojquery core.
> 
> What do you think? Do you have better ideas? I hope I can put up some
> code soon. I haven't coded the $.map() stuff yet. I just stopped when I
> was hitting the $().map() wall :)
> 
> Cheers,
>   Volker
> 




More information about the Mapquery mailing list