Hi,
This community module will allow entering specific request parameters as
URL path fragments (*REST like URLs*) instead of using the query string.
For example, we want to be able to apply a cql_filter using a URL in the
following form:
http://<host>:<port>/geoserver/<workspace>/<layer>*/<filter>/*
ows?service=WMS&version=1.3.0&request=GetMap
As a simple example of usage, if the <filter> is something like:
cql_filter=seq='*K140M*'
the URL would become:
http://<host>:<port>/geoserver/<workspace>/<layer>/*K140M**/*
ows?service=WMS&version=1.3.0&request=GetMap
and the proposed community module will translate the URL to this new one:
http://<host>:<port>/geoserver/<workspace>/<layer>/
ows?service=WMS&version=1.3.0&request=GetMap&*cql_filter=seq='K140M'*
This community module could be used to enable *REST like URLs* for clients
that are not able to consume OGC protocols directly.
This module is configured by a set of rules that will allow us to select
the URLs that should be transformed and describe the transformation to be
applied:
<Rules>
<Rule *match*="^.*?(/(a-zA-Z0-9_\-]+))/[^/]+$"
*parameter*="cql_filter"
*remove*="$1"
*transform*="seq='$2'"/>
<Rule .../>
</Rules>
The *match *attribute contains a Java Regular Expression
<https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html>
that is used for two proposes:
- selecting the URLs that should be transformed
- extract the pieces of information (*groups*) than can be used to
describe the transformation.
The *parameter *attribute defines the parameter that should be added to the
query, in this case the 'cql_filter' parameter.
The *remove *attribute must reference a valid group of the *match *expression
(typically the must external one) which will be removed from the original
URL.
The *transform *attribute defines the parameter value content. The
*transform* string can reference any valid group of the *match* expression.
This module can be implemented as Servlet Filter which will give us total
control over when it should be executed (regarding the filters chain), but
this will make it harder to implement a "plug and play" behavior.
Another option is to implement this module as a filter that extends the
*GeoServerFilter* and *ExtensionPriority *interfaces, this will make very
easy to implement the "plug and play" behavior but the filter will be
executed by the
*SpringDelegatingFilter* filter which is executed only after the
*AdvancedDispatchFilter* filter and I'm not sure to understand all the
implications of this.
Any feedback on this is welcome.
Best regards,
Nuno Oliveira
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
