Those are a couple of really good points Justin.
I hadn't considered that other code might be using HttpServletRequest.getParameterValue() directly, but you're right that this may very well break things. So I guess that rules out the general case of 'extending' parameters that way.
Andrea had brought up yesterday (and over the last couple of days, I think) the idea of extending the FORMAT= parameter in exactly that way, however. It's entirely possible that I mis-interpreted that idea, though, so I'd love to hear Andrea's call on the FORMAT= parameter and all this stuff.
I like the idea of VENDOR_OPTIONS as a general tag with colon-seperated, comma-delimeted KVPs, and a general
List Request.getVendorOptions()
method. I guess I'd rather see the main parameter called "GEOSERVER_OPTIONS" rather than VENDOR_OPTIONS, but if VENDOR_OPTIONS is the OGC-approved tag, then I guess we should go that route.
Is there an approved way to map VENDOR_OPTIONS=a:b,c:d from XML requests? Or would it be done ad-hoc by the individual request XML parsers?
--saul
________________________________
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wed 6/6/2007 7:34 PM
To: Farber, Saul (EEA)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] openlayers output format
I am a little weary of "extending" existing parameters in this way. If
so we would have to do one of two things.
1. Pre-parse all kvp and split out the vendor options or:
2. Have the "getValue" method on KvpRequestReader handle this and
essentially do what "getStandardOption" does
Also (I am not sure) but i believe there is code that directly accesses
kvp through HttpServerRequest.getParameters(), so that code could
potentially break.
I also believe this falls apart when a kvp allows a ";" as part of its
value space. IE. how do you know if the first ";" is part of the value
proper, or the start of vendor options.
The nice thing about doing it entirely in a separate kvp is that we have
full control over what "allowable" values are. IE. if we say semi column
means start of vendor option, then thats what it means. We don't have to
worry about a new spec or something coming along which introduces a semi
colon as an allowable value.
So how about this. We use the "VENDOR_OPTIONS" key name, but we change
its format slightly so that the first "token" is the kvp we are
extending. So for example, rewriting your examples would be:
'FORMAT=application/openlayers&VENDOR_OPTIONS=FORMAT,layerGrouping:on,bells:off,whistles:on'
'TRANSPARENT=true&VENDOR_OPTIONS=TRANSPARENT,model:singlePixelTransparency,alphaBlending:2layersdown'
This way all the old kvp code does not have to change at all. We can
still have the method for looking up a vendor option be:
List getVendorOptions( String key );
What do you think?
Farber, Saul (EEA) wrote:
Justin,
Cool, thanks for the historic info.
I think it's useful enough, however, to have a many-layer version as a non-default option on the application/openlayers outputformat.
As for where to put the vendor parameters, here's what's in my head:
For a given operation (GetMap, GetFeature, GetCoverage, etc.) on a given service, we should decide ahead of time which EXISTING parameters are 'vendor-extendable'. This will probably change over time, as people add options to geoserver requests (like this openlayers one)
These parameters are things like 'FORMAT=application/openlayers;layerGrouping:on,bells:off,whistles:on'
or
'TRANSPARENT=true;model:singlePixelTransparency,alphaBlending:2layersdown'
where an existing parameter is 'vendor-extended' by adding a semi-colon after the expected value, and comma-delimited, colon-seperated KVPs follow.
(the last one is a stretch, but it's just an example)
There should be a convenience method on Request which will parse an 'extended' parameter like these. Something like this:
public static List getVendorOptions(rawString) {
//discard the 'real' value
//collect a String of the remaining colon-delimeted pairs
}
and
public static String getStandardOption(rawString) {
return [string off everything after the ';' in rawString ,if there is one]
}
This allows the Request subclasses (by way of their respective XML and KVP readers) to store the vendorOptions as a list (if they want to) or to just store the whole raw string, knowing that convenience methods exist to pull out the vendor params in the actual operation code later.
By the way, I think the return type should be a List, because parameters may not necessarily be unique (think COVERAGE_OPTION=BANDA;red:band1,red:band2,blue:band3 or another situation where the keys might not be unique)
Seperately from this, fully optional vendor parameters could potentially exist on all requests, but I'm not sure what the advantage to
Map Request.getVendorParameters()
is over just using
HttpServletRequest.getParameterValue()
for raw parametetrs, or actually doing the parsing and creating getters/setters for more 'formalized' optional parameters.
Thoughts?
--saul
________________________________
From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Wed 6/6/2007 6:37 PM
To: Farber, Saul (EEA)
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] openlayers output format
Hi Saul,
This is actually how the output format was originally written, however
Andrea had an argument for grouping them. I cant remember exactly what
it was but at the time it was compelling enough to convince me :).
About the vendor params I think this is something we probably want to
put on GetMapRequest object directly. Or better yet directly on Request
so that all requests can use it. Perhaps something like:
class Request {
...
Map getVendorParameters();
...
}
Also... thinking toward 1.6.x.. i have a question. As some know the
dispatcher on trunk pre-parses all kvp's which are supplied in a
request. Do we want to apply this to vendor parameters as well? Or just
keep them as raw strings?
-Justin
Farber, Saul (EEA) wrote:
Hey all,
I was looking at the openlayers output format today, and I noticed that if you request multiple layers, they all get grouped into one aggregate 'Geoserver Layers' base layer.
It'd be really cool to allow users to turn 'upper' layers on and off, so I modified the outputformat to support this.
However, it's worth noting that this increases the load on a server by a factor of the number of layers requested. So if someone requested four layers with an outputformat of "applictation/openlayers" they're going to increase the stress on their server by four times as much as they used to.
Do others think this is a useful addition/modification? I think the best answer is a vendor-specific parameter on the output format, something like:
&format=application/openlayers,groupLayers:[true|false]
With the default set to...well, I don't know which is appropriate for the default.
There's been lots of talk of vendor parameters lately, and I really like Andrea's suggestion of comma-delimited, colon-assigned parameters. Should we change some of the underlying code in GetMapRequest to support this, or is this something that can be handled on an outputformat by outputformat basis?
--saul
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
!DSPAM:4007,46673eb6194526491211187!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com