[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