[OpenLayers-Dev] constructor signatures

Björn Harrtell bjorn.harrtell at gmail.com
Tue Jul 20 05:31:35 EDT 2010


I was about to write a separate mail to the dev list about this but
saw this discussion so I'll just join it. It seems like the discussion
wasn't really conclusive?

I also in favor the single object argument approach. The main reason
for this is probably too much Ext Js coding, but at the moment I'm
finding the multiple argument construction of Layer-subclasses really
annoying since I need to serialize/deserialize metadata describing
what to create. Here is my few other points:

1. "options" isn't always optional (at least in the logical sense) it
seems - for instance when creating OpenLayers.Filter.Spatial
instances.

2. Classes in openlayers that have an obvious primitive representation
does not allow that representation to be used implicitly. One obvious
example is OpenLayers.Bounds which I think would be great if the array
(and/or string, personally I prefer the array) representation was
accepted as input when constructing. I guess this is kind of similar
to the idea of lazy initialization in Ext Js.

My points aside, I would assume that for 3.0 this discussion needs
conslusion and perhaps I can still dream about a total refactor to
consistent single object arguments approach for 3.0? :)

/Björn

2010/6/18 Peter Robins <openlayers at peterrobins.co.uk>:
> On 18 June 2010 16:53,  <christopher.schmidt at nokia.com> wrote:
>> I regularly use a WMS server with no 'layers' param. I know that this
>> is a special case, but the layer does not technically require this
>> parameter to work. (Your server might; the spec might even, but
>> the parameters that are required depend on your server.)
>
> a situation I've often found with WMS servers is that the (WMS) params
> depend on the state of the map; having the layers param dependent on
> zoomlevel is a common issue. In some cases, I'm even using different
> servers depending on the zoomlevel. In this case, you can't specify
> the WMS params in the constructor, but only in a custom moveTo or
> whatever.
>
> So to me the key point is not whether a particular property is
> necessary for a particular method in the object to function, but
> whether it has to be present in the constructor. I would guess that
> the number of truly required params (i.e. the object can't be
> constructed without it) is very small.
>
> To me, the big advantage of OL (and JS) is it's very flexible, and
> allows me to change more or less any property or method whenever
> necessary. Requiring me to enter something in the constructor param
> (WMS params in the case above) even if I don't know at that point what
> it should be seems like unnecessary bureaucracy to me, and IMO it
> would be better simply to document what happens if certain params are
> or are not present.
>
> Anyway, that fits in better with the name 'options' - by definition,
> all options are optional :-)
>
> FWIW, I favour the single object argument, though it's not something I
> would man the barricades about.
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>



More information about the Dev mailing list