[geojquery] To plug in or not to plug in?

[Just van den Broecke]

Hi All,

I have been pondering on the same question. I am a fan of both JQuery 
(JQ) and OpenLayers (OL). IMHO both are top-notch products when it comes 
to elegance of design and usage. As all software is about abstraction, 
both JQ and OL are abstracting their respective target domains, JQ: the 
DOM and its manipulation, OL: components around web-mapping/geospatial, 
both visual e.g. maps, and non-visual e.g. back-end services 
(OGC/non-OGC). Also, each has its own software design-paradigm, OL: 
object-based/oriented and JQ DOM-oriented, functional almost Lisp-like. 
Both have extensibility options, JQ by design, like plugins and OL 
through "standard" OO-(sub)classing.

How shall the twain meet (to quote from another British writer) ? Unless 
our application is just a map with some layers, OL is sufficient, but 
IRL we have to provide a full-blown web-client with both geospatial and 
non-geospatial  gui/application features (or "business" and "mapping", 
dependent on your POV). A single all-encompassing framework with a 
single API seems compelling...

Several of these libraries, both in the past and currently, have been 
attempted or are arising. Possibly you have heard about (Community) 
MapBuilder, http://communitymapbuilder.org (CMB). CMB is not just a 
mapping library, but a complete/extensible Ajax-framework designed 
around the Model-View-Controller design-pattern. So basically CMB could 
be our framework. CMB was probably ahead of its time and the 
JS-engines/bandwidths of those days (<2006), but I think somewhere in 
2006 OL emerged and took off like a comet, IMO also as a more 
accessible/understandable/lightweight alternative to CMB (check). But 
then later OL by itself appeared not to be sufficient as a complete 
client-framework, so several attempts emerged to go again for the 
"all-encompassing": hence emerged GeoExt (http://geoext.org), to combine 
a framework (ExtJS) and a library (OL) using mainly ExtJS's paradigm to 
extend new services/datastores/widgets.

I don't know exactly the audience on this list (I got here through 
Arnulf's tweet) but appearently there is a need (like with me) to 
combine the best of both JQ and OL in functionality, "weight" (e.g. for 
mobile webclients), extensibility, "graspability" and possibly OSS 
licensing policies. The problem is the design-paradigm to use: OL as 
JQ-plugin is one candidate.

So back to Oliver's question, I think he is making a very valid point, 
and I would like to add: IMHO a JQ plugin will add another layer/wrapper 
around OL for ease-of-use without adding functional value. This may be 
of use for a particular group of developers that need easy access to 
web-mapping. Libraries like http://www.mapstraction.com may cater for 
that. I am still seeking/hoping for a JQ+OL approach that is at least 
the sum of its parts. That is why I was happy to see the BOF and this 
list emerging. Given past and present I think it is good to do upfront 
brainstorms and pose questions like Oliver's before embarking into 
development.

To add some thoughts: when I first used OL in 2007, I saw its design as 
an prime example of "JavaScript done right". At some point I played with 
the idea to have OL as the basis of a full blown Ajax framework, 
possibly even wrapping JQ when it comes to DOM-manipulation. This idea 
is probably too far-fetched. JQ presents the NKOTB, state-of-the-art 
JavaScript, OL uses parts from JQ's predessor Prototype.js, so going 
with the JQ paradigm seems the way to go. Ultimately one could think of 
a rewrite of OL according to JQ-plugins. This again will tie OL too much 
to a single JS-framework. Maybe a form of automated code 
transformation/generation from an OL core code base to 
JQ-plugins/ExtJS/.. even Java/Flex/Flash (generating OpenScales!) could 
be possible...

My $2ct, best,

--Just

Just van den Broecke
The Netherlands
http://www.justobjects.nl

Oliver Tonnhofer wrote:
> Hi everyone,
> 
> I was playing with the jQuery plugin idea and I am not really sure if a plugin is the right way for doing this.
> 
> All existing jQuery plugins are - more or less - just playing with DOM objects. Hide that, fade this in, add this event, etc.  But we want to work with another library, we don't need access to the DOM elements where we added our maps, we need access to the actual map object (OpenLayer or our own geojquery map objects).
> 
> I don't see how this can be implemented in an elegant way when we just want to write a plugin. 
> 
> Let me give you an example with some code I have[1]:
> 
> $('#map').map({
>  size: [400, 400],
>  zoom: 7,
>  center: [8.19884, 53.1495],
>  layers: [$.map.tms({host:"http://osm.omniscale.net/proxy/tiles/", layer:"osm_EPSG900913"})]
> });
> 
> Pretty simple. I just created a map inside the #map element. But how do I interact with the map? $('#map') gives me a jQuery object where I can manipulate all attributes from the DOM object, but not the actual map. We can add the OpenLayers map or some geojQuery object as .data() to the element, but $('#map').data('map').center(lonlat) is rather quirky.
> 
> One solution would be to add another jQuery method for everything we intend to do with our map.
> 
> $('#map').center(lonlat);
> $('#map').add_layer(...);
> 
> That would work, but it would also pollute the $-namespace. PHP developers might like that but I'm strongly against that. ;)
> 
> Maybe I'm missing something, please enlighten me :)
> 
> [1] http://bitbucket.org/olt/geojquery-playground/src/
> 
> Regards, 
> Oliver
>