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

Andreas Hocevar ahocevar at opengeo.org
Tue Jul 26 05:52:10 EDT 2011


Hi Richard,

one note about license and patents: OpenLayers 2.11 is released under a simplified license, which does not contain any language about patent rights. See http://openlayers.org/blog/2011/05/17/simplified-license/

Also, please let me know if you're able to override constructors in 2.11 with this approach:

var A = OpenLayers.Class({...});
var B = OpenLayers.Class(A, {...});

OverloadB = {
    initialize: function() {...},
    customMethod: function() {...},
    customProperty: "foo"
};
var BTemp = OverloadB.initialize;
BTemp.prototpye = B.prototype;
OpenLayers.Util.extend(BTemp.prototype, OverloadB);
B = BTemp;

Andreas.

On Jul 26, 2011, at 11:32 , Richard Didier wrote:

> 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
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev

-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.



More information about the Dev mailing list