Following the discussion between Paul & Eric has really shown the dichotomy of
opinions regarding the map vs layers as master controller and reveals the
reason for the baseLayer paradigm in the first place.
I think the common use cases are for maps with a background layer are:
1. Fixed resolution, fixed projection tile sets in "Google Maps" configuration
2. Fixed resolution, fixed projection tile sets in a local coordinate system
and/or non-Google tiling scheme
3. WMS free resolution, free projection background
Using any of these by themselves is generally pretty easy and makes little
difference to most users if the map or a base layer controls the map
properties. Admittedly it is confusing to configure your map and your base
layer with similar options but no direct documentation that the base layer wins
in nearly all options and overwrites whatever you have for your map as is the
case in OL 2. For these users, there is no question that moving the
configuration to the map makes more sense.
The problems start happening when users want to mix and match the 3 background
types and switch easily between them. The real issue is what object will add a
reconfigure map event to the map.
With Paul's proposal of the map object is in absolute control of all of the
layers that it displays and convenience functions that do "magic" map
reconfiguration should be moved to preconfigured event handlers in map
configuration options or even further removed all the way out to UI controls.
With Eric's proposal, you get the magic map reconfiguration behavior added in
when you set a layer configuration option indicating that it is a "Master"
layer.
I think fundamentally at a basic underlying code level the 2 proposals are
quite similar. However, there is a big difference in the API depending on which
way you go. I personally think that setting the map as a Google style map makes
the mixing of background layer types, too difficult for novice API users. I
also think that configuring the map with a set of valid resolutions, maxExtent,
projection combinations and having to include layers that match at least one of
those combinations in the map makes the API much less straight-forward.
I would propose that _Yes_ the map is the one that controls all the other
layers and anytime you reconfigure the map it should reconfigure those layers
that it can and stop displaying / disable the layers that it can not. However,
I think it makes a lot of sense from an API point to have a Master layer type
option. Basically all this layer has is a preconfigured event handler that
listens for the setVisiblity event and fires a reconfigure map function using
the layer's projection, resolutions , and maxExtent options. However, unlike in
Eric's proposal, any other layers configured as Master layers would only get
turned off / disabled if they were incompatible with the reconfigured map. I
think the automatic turning on/off of compatible layers and the idea of layer
groups IS better handled by UI controls or some other place than the
fundamental building blocks of map & layers.
Matt Priour
Kestrel Computer Consulting
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
