Hi,
trying to implement the component WMS specification
I noticed two things that I cannot do with isolated
kvp parsers.
The first one is SLD library mode, that is a request
like:
...?request=getMap&layers=...&styles=...&sld=...
where the sld is managed as a library of styles
that are referred from the styles parameter (you
fist look into the library, if you don't find anything,
you look in the server styles).
This would fail because the StylesKVPParser parser
only looks in the GeoServer catalog and throws an exception
if a style is not found.
The second one is using a remote wfs server as a data
source, something you do, by spec, with the following
request:
...?request=getMap&layers=...&REMOTE_OWS_TYPE=wfs&REMOTE_OWS_URL=urlToWfs
In this case the layers are supposed to be provided
from the remove WFS, which is something provided on
the fly, not a configured datastore.
In both cases the limitation I find is that I need to
parse some parmeters by first knowing about the presence
and contents of other parameters.
This may be solved by declaring kvp parsers dependencies
and allow them to be given info from other kvp parser
results (a "high tech" solution) or by killing the
kvp parsers and do everything in the WMSKvpReader
(the "low tech, do it now" solution).
Problem is, I need to do this today and do it on trunk.
So... the idea I have at the moment is to un-register
the above kvp parsers from the application context,
so that the dispatcher won't try to use them directly,
pump them up with extra setters to give them the extra
contextual information they need, and then have the
WMSKvpReader to call them directly. This may well
make the WMSKvpReader less crowded too
Cheers
Andrea
Andrea Aime wrote:
Hi,
trying to implement the component WMS specification
I noticed two things that I cannot do with isolated
kvp parsers.
The first one is SLD library mode, that is a request
like:
...?request=getMap&layers=...&styles=...&sld=...
where the sld is managed as a library of styles
that are referred from the styles parameter (you
fist look into the library, if you don't find anything,
you look in the server styles).
This would fail because the StylesKVPParser parser
only looks in the GeoServer catalog and throws an exception
if a style is not found.
The second one is using a remote wfs server as a data
source, something you do, by spec, with the following
request:
...?request=getMap&layers=...&REMOTE_OWS_TYPE=wfs&REMOTE_OWS_URL=urlToWfs
In this case the layers are supposed to be provided
from the remove WFS, which is something provided on
the fly, not a configured datastore.
In both cases the limitation I find is that I need to
parse some parmeters by first knowing about the presence
and contents of other parameters.
This may be solved by declaring kvp parsers dependencies
and allow them to be given info from other kvp parser
results (a "high tech" solution) or by killing the
kvp parsers and do everything in the WMSKvpReader
(the "low tech, do it now" solution).
The KvpParser interface is not meant to do this sort of logic. Its just
meant to create simple data objects. This sort of logic was intended to
go into the KvpRequestReaders, which do any post processing on the
request objects.
Problem is, I need to do this today and do it on trunk.
So... the idea I have at the moment is to un-register
the above kvp parsers from the application context,
so that the dispatcher won't try to use them directly,
pump them up with extra setters to give them the extra
contextual information they need, and then have the
WMSKvpReader to call them directly. This may well
make the WMSKvpReader less crowded too
Instead I would prefer that you just modify the request object. Add the
folloowing parameters to it:
getRemoteOWS()
getLibrarySLD()
Create "simple" kvp parsers for them. And then processes them in a
KvpRequestReader in order to populate other parts of the request object.
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,4718bd9a260541849620573!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Hi,
trying to implement the component WMS specification
I noticed two things that I cannot do with isolated
kvp parsers.
The first one is SLD library mode, that is a request
like:
...?request=getMap&layers=...&styles=...&sld=...
where the sld is managed as a library of styles
that are referred from the styles parameter (you
fist look into the library, if you don't find anything,
you look in the server styles).
This would fail because the StylesKVPParser parser
only looks in the GeoServer catalog and throws an exception
if a style is not found.
The second one is using a remote wfs server as a data
source, something you do, by spec, with the following
request:
...?request=getMap&layers=...&REMOTE_OWS_TYPE=wfs&REMOTE_OWS_URL=urlToWfs
In this case the layers are supposed to be provided
from the remove WFS, which is something provided on
the fly, not a configured datastore.
In both cases the limitation I find is that I need to
parse some parmeters by first knowing about the presence
and contents of other parameters.
This may be solved by declaring kvp parsers dependencies
and allow them to be given info from other kvp parser
results (a "high tech" solution) or by killing the
kvp parsers and do everything in the WMSKvpReader
(the "low tech, do it now" solution).
The KvpParser interface is not meant to do this sort of logic. Its just
meant to create simple data objects. This sort of logic was intended to
go into the KvpRequestReaders, which do any post processing on the
request objects.
Problem is, I need to do this today and do it on trunk.
So... the idea I have at the moment is to un-register
the above kvp parsers from the application context,
so that the dispatcher won't try to use them directly,
pump them up with extra setters to give them the extra
contextual information they need, and then have the
WMSKvpReader to call them directly. This may well
make the WMSKvpReader less crowded too
Instead I would prefer that you just modify the request object. Add the
folloowing parameters to it:
getRemoteOWS()
getLibrarySLD()
Create "simple" kvp parsers for them. And then processes them in a
KvpRequestReader in order to populate other parts of the request object.
I'm sorry, but how the current parsing of layers and styles
would use them? Those two parsers are isolated, they cannot function
according to the spec without knowing if there is an SLD and a
remoteows.
Plus, there is no such a thing as a "librarysdl" parameter, that's
just a mode of operation that uses sld=xxx or sld_body=xx and
engages (according to the spec) when both layers and styles
parameters are in the same request (see the issue I just opened).
Cheers
Andrea
I'm sorry, but how the current parsing of layers and styles
would use them? Those two parsers are isolated, they cannot function
according to the spec without knowing if there is an SLD and a
remoteows.
Plus, there is no such a thing as a "librarysdl" parameter, that's
just a mode of operation that uses sld=xxx or sld_body=xx and
engages (according to the spec) when both layers and styles
parameters are in the same request (see the issue I just opened).
Sorry for not being 100% precise. All i meant was to add some simple
java bean properties to the request object in order to capture anything
needed from the kvp parsers, and then process them after in the kvp
request reader.
Am I making sense? Perhaps we should take this up on irc.
Cheers
Andrea
!DSPAM:4007,4718d4b45607180515871!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org