[geojquery] First code for scoping-change approach

[Volker Mische]

Hi Eric,

Eric Lemoine wrote:
> On Saturday, March 20, 2010, Volker Mische <volker.mische at gmail.com> wrote:
>> Hi Marc,
>>
>> I like the "evererything is a plugin" a approach. I'll try to adapt in
>> my code. I really like the way ideas comes up. When we both keep adding
>> the things we like from each other's implementation we might even end up
>> with two implementations of the same public API :)
> 
> Hi
> 
> I just took a look at the code of jQuery UI. As you probably know
> jQuery UI is a collection of jQuery plugins. And the API of jQuery UI
> looks interesting to me.
> 
> To create a widget:
> $("selector").theWidget(options);
> 
> To call a method on the widget:
> $("selector").theWidget("methodName", options);
> 
> For this to work the widget object is stored using $.data().
> 
> For geojquery one could imagine a similar API.  For example to create
> a map and add layers to it one would do:
> 
> $("#map").geo(mapOptions);
> $("#map").geo("addLayers",  [
>     new OpenLayers.Layer.WMS(...)
> ]);
> 
> The above example assumes that the OpenLayers.Map instance is itself
> stored in the data object and that there's no intermediate object.
> 
> Also, the more I think about it the more I think the geo() (or
> whatever it's called) function should return a jQuery object as
> opposed to a map instance. geojquery being about providing a
> jQuery'ish API I think this is important.
> 
> Just thoughts. And my sincere apologies if this isn't relevant to the
> current discussions, and for just throwing ideas without writing
> actual code.
> 
> Cheers,

I personally don't like the jQuery UI approach too much. It suits the UI
project well, as they always want to return a jQuery object to keep
chainable.

I don't really see the point why we should return a jQuery object. From
a practical perspective, how often would you want to manipulate the map,
and often do you want to manipulate the DOM node it was applied to.

To come back to jQuery UI. Most of their widgets are drop in
replacements for HTML elements. You normally just instanciate such
widgets and never care about them. You don't call methods that often,
and if, they are quite simple (like changing a to another tab).

In geojquery you interact on several levels. You have a map, layers and
features. Have a single entry point which returns a jQuery object
doesn't sound suitable to me (rather than having a jq() method).

But perhaps we are talking about different things. I want for geogquery
core an easier way (easier than the OpenLayers API) to operate with map
objects. This should make rich widget development (like a layer control)
easier and more jQuery-ish. On top of that there could of course be a
simple "geo" widget, that you just start with some options, it will
create a map and return a jQuery object. But that's would be already
part of geojquer UI.

To come to a conclusion (I could delete the reasoning above, but it
might be interesting for others):
1. I like to see a simple consistent API for map interaction that could
be used to build widgets based on jQuery (geojquery core).
2. Those widgets that use that API, from a simple one that just created
a map, to more complex ones like layer switchers, will then always
return a jQuery object and might have an API that resembles the jQuery
UI style (geojquery ui).

And finally: thanks Eric, any input is relevant for the discussions.

Cheers,
  Volker