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

[Jan Schorn]

Hi,
thanks all to the interesting discussion!

We are quite convinced that it's a good idea to work both approaches, 
the core and UI one.

It seems to be really useful develop the core first, and then the 
components based on the core using the full funcionality of jquery like 
$("#features").each() (thanks Volker), say implementing the UI the way 
mapbender does described by Christoph.

Well, our interest is to work as fast as posible with some UI components.
 
So, our problem is that we will need to wait the time it will take to 
develop the core - we won't have the components we need right now.
Our idea is to develop some components the next months with the help of 
a specific project.

What do you think about developing some UI components directly with the 
OpenLayers API and if the core is terminated, modify them to use them 
the way, for example, mapbender does?

Do you see any posibility to coordinate in some way UI and core 
development to cover the goales of both aproaches?

cheers,
Jan


Christoph Baudson (Wheregroup) wrote:
> Volker Mische schrieb:
>> Oliver Tonnhofer wrote:
>>  
>>> On 13.03.2010, at 21:48, Volker Mische wrote:
>>>   
>>>> the way I have imagined it is like gquery does it. Once you apply the
>>>> map object, you are not in the DOM world any more. Any future call in
>>>> the chain will be applied to the map. Here's an example:
>>>>
>>>> $('#map').map({someoptions}).center(lonlat);
>>>> [...]
>>>> $('#map').map({someoptions}).center(lonlat).dom().hide();
>>>>       
>>> Ok, that looks not to bad. How do you think we retrieve the map 
>>> object again later? We could store the object with .data() and 
>>> return this object on subsequent .map() calls.
>>>
>>> $('#map').map({someoptions})
>>> // later
>>> $('#map').map().center(lonlat);
>>>     
>>
>> Yes, the data should be internally stored with data(). Just like jQuery
>> UI does it.
>>   
>
>
> This is already a very promising discussion, thanks to everyone involved.
>
> I just wanted to share an aspect of how jQuery is used in Mapbender. 
> There is a plugin "mapbender", like "map" in the example above. Called 
> without any parameters, it behaves like Volker explained above, it 
> returns the JS object stored via data(), not the jQuery collection.
>
> However, sometimes we found it useful to to have a method actually 
> return values, which would prevent chaining. We have added the option 
> to pass a function to the plugin, which is executed within the scope 
> of the Mapbender object, so you could write code like this
>
> $('#map').mapbender(function () {
>   var foo = this.bar(); // "this" refers to the JS map object
>   // etc.
> }).hide();
>
> The upside for us was to be able to execute more complex code within 
> the closure, and still be able to chain. I'm not sure if it's suitable 
> for GeoJQuery, or good style in general, but we are comfortable with it.
>
> Personally I dislike the UI style of operating on a plugin, like
>
> .datepicker( 'dialog' , date , [onSelect] , [settings] , [pos] )
>
> I find it clumsy, but I may not have understood the full effect of 
> doing it this way. Maybe some of you have.
>
> The Mapbender Plugin follows the "GeoJQuery UI" approach, so I would 
> be especially interested in this, not saying that I wouldn't be 
> interested in the "GeoJQuery Core" approach :-)
>
> Christoph
>
>
>>  
>>> It would be cool to have working CSS selectors like
>>> $('#map #mylayer').hide(). It might work some custom selectors 
>>> $('#map :layer("mylayer")').layer().disable()
>>>     
>>
>> Custom selectors should be easily possible, though I haven't used them
>> myself.
>>
>> Cheers,
>>   Volker
>>
>> _______________________________________________
>> Geojquery mailing list
>> Geojquery at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geojquery
>>   
>
>