On Jun 18, 2010, at 11:02 AM, ext Tim Schaub wrote: > To clarify here, specifically for the WMTS layer, these are the strictly > required properties: > > * url > * layer identifier > * style identifier > * matrixSet identifier > > And who knows, we might get smarter in the future and find that we can > derive sensible defaults for those*. Anyway, at least four required > arguments to start with. And by required I mean that the layer will not > render anything when added to a map if those arguments are not provided. > I'm putting together a patch for the layer that will make the > constructor throw an error when the layer is not properly configured - > to reduce the chance for user error.
A good plan. And stuff like this -- specifically, the potential that the defaults could *change* in the future -- is the kind of thing that makes the current 'required are seperate from not required' silly. (In a WMS layer, 'params' is required -- but in reality, there's no reason you *have* to have parameters for a given layer -- same kind of problem.) > Having a single argument for the WMTS layer constructor also makes > things nicer for creating layers from parsed capabilities. This is a > detail specific to the WMTS layer, but I had it in mind when making the > decision. In general, a single configuration argument is more > convenient to pass around, extend, serialize (assuming people want to > persist app configuration), etc. I'm reasonably convinced that this is the right thing for the future. >> Backing out on something that is one of our few points of consistency -- >> Layers require a string as their first argument -- would make me >> sad, but I'm not going to argue that we need to revert a change >> because of it. I just think it's a worthwhile convention to hold onto >> until we really go ahead and change many of our conventions for the >> Glorious Future. >> >> Going forward into 3.x, I am okay with abandoning this convention >> in favor of making everything optional. I don't like it, personally, >> but if this is common Javascript convention, I'm willing to go with >> it. >> > > I completely understand this. I suspected this was about a change that > would make you sad. > > So, right now we have an opportunity. We can create new constructors > that are forward compatible, or we can create new constructors that > follow old conventions (and need to be changed in the future). > > I hear that you (Chris), Eric, and Bart favor going with old conventions > rather than forward compatibility. That about sums it up. :) Regards, -- Christopher Schmidt Nokia _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
