Roald,
On Nov 29, 2007 2:08 AM, Roald de Wit <[EMAIL PROTECTED]> wrote:
> This is a tricky one: the layerNames come from the config.xml of the
> app. Example: wfs-t:
> <OverviewMap id="locatorWidget">
> <htmlTagId>locatorMap</htmlTagId>
> <width>180</width>
> <layers>
> <layerName>basic</layerName>
> <layerName>topp:tasmania_water_bodies</layerName>
> <layerName>topp:tasmania_roads</layerName>
> <layerName>topp:tasmania_cities</layerName>
> </layers>
> </OverviewMap>
Actually, we were too aware that this is a suboptimal solution. And I
wanted to have layerIDs back then, only we had no ressources to do it.
Now that you did such a great job in introducing them, I would propose
the following:
> For this to work on layers that have an @id, you would have to replace
> the node value of the corresponding layer name with the value of the
> layer id.
We could also do something like
<layers>
<layerId>tasmania_water</layerId>
<layerName>topp:tasmania_cities</layerName>
<layers>
> Is that desired functionality? Or should we create a fail safe mechanism
> for this as well? Like: try to find the oLlayer by the value of that
> node, if not, find the layer in the context, retrieve its @id value and
> try to find the oLlayer with that @id.
The above would allow application developers to work with either
layerId or layerName. In the case of layer names, a lookup would have
to be done to get the according layer id.
I would propose to add a function in MapPaneOL:
this.getLayerIdByName = function(objRef, layerName) {
// do some stuff here to look up the layerId
return layerId;
}
Of course, this can only return the first layer found in the context
matching the layerName, but that is exactly what we had before your
enhancement. This function would help application developers to make
widgets relying on layer names compatible with the new ids.
> This leads me to question whether or not we should generate our own @id
> at all (in OwsContext for example) when there is none...
I think we should.
> Please give me your opionion.
If you are able to make the proposed changes, this would be perfect.
And I would be glad to have your work in 1.5. I tested the current
trunk version with all my real-life applications, and they work. Which
is very good.
Thanks!
Andreas.
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
mapbuilder-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
