[OpenLayers-Dev] Independent UI Controls

[Tim Schaub]

Thanks for the efforts Volker.

I think it would be good to separate things a bit in this discussion.

One line of discussion could be about how to make OpenLayers work better 
with existing widget frameworks (or other ones yet to be created).

A second line of discussion could be about creating a series of adapters 
for existing widget frameworks.

Your jq-zoom.html example demonstrates a bit of the second and suggests 
that the first is not strictly necessary (in the case of basic map 
navigation).

In the case of GeoExt, our idea was to make it so that people coming in 
with experience with an existing widget framework (large pool) could 
start using map related functionality with syntax that is consistent 
with the existing widget framework.

Regardless of which you think has more utility (using OpenLayers syntax 
and delegating to the widget framework for the UI vs. using widget 
framework syntax and delegating to OpenLayers for the mapping), both 
approaches could potentially benefit from changes to OpenLayers.

I like the idea of starting to develop OpenLayers controls that don't 
add any redundancy or extra overhead (think dom elements and event 
listeners) when another widget framework is in use.

Whatever we do, I don't see the sense in working on anything that limits 
folks to the lowest common denominator of all (supported) widget frameworks.

Interested to hear what others think.

Tim

Volker Mische wrote:
> Dropping some code into the wild doesn't seem to be the right way to
> start a discussion. But hopefully this mail will.
> 
> I've updated the example at [1] a bit. It now shows the usage of
> jQuery and Dojo. Especially interesting is the code of the
> OpenLayers.Control.ZoomSlider [2], it's an implementation that
> resembles the GeoExt.ZoomSlider.
> 
> The question is: Is it a good idea to create OpenLayers controls that
> are independent of the underlying JavaScript library? This would push
> OpenLayers into the framework direction. You would embed functionality
> from a JavaScript lib into Openlayers. Or would it be better to leave
> OpenLayers (as it was meant to be) as a library and every JavaScript
> lib creates its own widgets and embeds OpenLayers. If the library-way
> is prefered, should devs even be discouraged from creating new
> controls based on raw JavaScript/OpenLayers and not on a lib?
> 
> Creating JavaScript lib independent controls would be a chance to
> collaborate accros libs (how great would it be to team up the GeoExt
> ppl with the jQuerz fanboys). But I'm well aware that GeoExt is
> already going down the other way, and based on the maturity it already
> has, it seems almost impossible to change the direction.
> 
> Cheers,
>   Volker
> 
> [1] http://dev.openlayers.org/sandbox/vmx/ui/examples/jq-zoom.html
> [2] http://dev.openlayers.org/sandbox/vmx/ui/lib/geojq/olui.js
> 
> On Thu, Feb 11, 2010 at 12:43 AM, Volker Mische <volker.mische at gmail.com> wrote:
>> Hi,
>>
>> at the FOSS4G 2009 at the OpenLayers BoF we discussed a bit that it
>> would be cool to have an easier way for integrating controls that are
>> based on other JavaScript libraries like jQuery, Dojo or ExtJs. At the
>> code sprint we (ahocevar, rdewit and I) got a bit more specific at the
>> whiteboard. No I finally managed to get some code done.
>>
>> Please have a look at my sandbox at an example:
>> http://dev.openlayers.org/sandbox/vmx/ui/examples/jq-zoom.html
>>
>> The buttons at the top could be OpenLayers ones, the others below are
>> jQuery UI ones. The important bits are at
>> http://dev.openlayers.org/sandbox/vmx/ui/lib/geojq/olui.js
>>
>> It's only a rough cut, but you should get the basic idea. The idea is to
>> separate the visualisation/representation of a control from the
>> functionality.
>>
>> What do you think about it? BTW: There are no changes to OpenLayers code
>> base.
>>
>> Cheers,
>>  Volker
>>
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.