[OpenLayers-Dev] 2.10 and 2.11-RC1 OpenLayers.Class behavior changes

[Richard Didier]

Le mardi 26 juillet 2011 10:57:23, Andreas Hocevar a écrit :
> Hi Didier,
> 

Andreas,

> > 
> > The rational is many fold :
> > 
> > 1/ There are tickets for the next OL release that we incorporate directly
> > in our production scripts. Usually, we try to push fixes every three
> > months and a new release a month or two after a new OL release;
> 
> You should apply these to the previous OpenLayers release.

Yeap, basically the idea is to have :

OpenLayers current release : never modified
overloadings (spread in different levels of functionnalities)
our library (splitted into different levels of functionnalities)
build tools and configuration files

This ensures us to be able to maintain through OL releases the overloadings by **never modifying the OL 
source code**.

> 
> > 2/ We insert patches directly in the OL classes tree (for instance, our
> > GeoDRM mechanism or bugs reported by users) and allow users to still use
> > OL's API but patched !
> 
> Instead, you should create subclasses for these. They could live in a
> separate namespace as well. If these patches are relevant for a broader
> audience, you could also consider contributing them to the OpenLayers
> project.
> 

It has been a long (long) talk with PSC members (like Christopher, Eric)... It is still aimed at contributing, but still 
legal hurdles to step over (patent stuff, copyright) : not easy to contribute as a public agency...

> > 3/ The OL library is split into several functional "ready to use"
> > libraries like : hooks to our JS library allowing developpers to use
> > whatever OL they want or GeoExt or ... Another example is to forge a
> > library without vector stuffs in, another to have mobile things, another
> > to have a small OL wrapper to talk with Flash, and so on ... For doing
> > that, we apply patches/overlay depending on the functionnality we aim
> > at.
> 
> For this, you can use the OpenLayers build tool, or any other build tool
> that allows you to create a build from only the files you specify. Again,
> these files can come from different source trees and namespaces.
> 

Agreed and applied !

> > The key issue is not to change OL API (Classes), possibly add new methods
> > to OL API. For functionnalities not in OL (mainly controlers), we have
> > our own namespace.
> 
> Good, so let's say you want to add functionality to the WMS layer, but
> don't want to contribute it to OpenLayers. The appropriate way to do this
> would be:
> 
> IGN.Layer.WMS = OpenLayers.Class(OpenLayers.Layer.WMS, {
>     initialize: function() { ... },
>     customMethod: function() { ... }
> });
> 
> In your application, you would create an instance of this custom WMS layer:
> 
> var myLayer = new IGN.Layer.WMS("ign", "http://ign.fr/wms", {layers:
> "ign"});
> 
> People can use this like any OpenLayers.Layer.WMS instance, plus use your
> customizations, e.g.
> 
> myLayer instanceof OpenLayers.Layer.WMS; // asserts true
> myLayer.customMethod(); // customization
> myLayer.setOpacity(.5); // OpenLayers.Layer.WMS method
> 

This is exactly what happens in our namespace...

> Andreas.

Sincerely,

didier
-- 
RICHARD Didier - Chef du pôle technique du Géoportail
2/4, avenue Pasteur - 94165 Saint Mandé Cedex
Tél : +33 (0) 1 43 98 83 23