On Tue, Apr 15, 2014 at 12:09 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Tue, Apr 15, 2014 at 10:16 AM, Sampo Savolainen <
> sampo.savolai...@spatineo.com> wrote:
>
>> Wondering, do you really have the evaluate filters against beans?
>>>
>>
>> My idea was to build a context for the stored query parameter evaluation
>> which would contain the following information:
>> - Values passed as view parameters
>> - Filter envelope
>>
>
> Have a look at ExtractBoundsFilterVisitor to extracts a bbox out of any
> random filter (assuming it's possible,
> otherwise no bounds will be extracted), you will not get just the bbox in
> the Query object
>
Yep. This is how I'm doing it.
>
>
- Feature type info
>>
>> The admin could then configure the layer to map these values to the
>> stored query parameters in the layer configuration like so:
>>
>> <StoredQueryConfiguration storedQueryId="urn::whatever..">
>> <ParameterMapping>
>> <ParameterName>bbox</ParameterName>
>> <ExpressionValue
>> language="MysticEL">${envelope.minx},${envelope.miny},${envelope.maxy},${envelope.maxy},${featureType.defaultCRS}</ExpressionValue>
>> </ParameterMapping>
>> <ParameterMapping>
>> <ParameterName>xyz</ParameterName>
>> <ExpressionValue language="MysticEL">${viewparam.xyz[0] * 60 *
>> 1000}</ExpressionValue>
>> </ParameterMapping>
>> <ParameterMapping>
>> <ParameterName>timestep</ParameterName>
>> <DefaultValue>720</DefaultValue>
>> </ParameterMapping>
>> </StoredQueryConfiguration>
>>
>> I'm using a hypothetical EL here to provide readability. The above xml
>> structure is raw, not much though has been put into it yet. Comments are
>> always appreciated.
>>
>> As in the example above, the same configuration could be used to provide
>> sane defaults to be used when no value is provided in the request.
>>
>>
>>
>>> But yes, I don't think there is any issue adding a javabean based
>>> property accessor (maybe check if you need to add dependencies though, like
>>> commons-beanutils, to make it run, or if the stuff you need is already
>>> there)
>>>
>>
>> Ok. I'll look into that once we get settled if I really need beans or not.
>>
>> Do you see a way to achieve what I proposed above without using beans? I
>> could always synthesize a simple feature type and use that as the CQL
>> context, but that seems like an awful amount of work (and kludges) to get
>> something pretty simple achieved.
>>
>
> The thing is, to parse a CQL expression you don't need a feature type, the
> parser just extracts the variable names you're providing
> as is, it's only at evaluation time that we try to use them, and discover
> if the feature has them, or not (well, we actually have some
> tools to compare the attributes required with the feature type, but that's
> something we do in order to provide nice error messages,
> in your case you can compare the variable values with whatever value you
> have in your context
>
True about parsing the expression. But when evaluating it, the context
object seems to have be a SimpleType. This is because the existing
accessors only support properties as they are encoded into SimpleType
objects, and for the accessor to access the properties, there must be a
schema that describes these properties. This is why I was looking into
creating a Java Beans based property accessor.
But you might be right that it could be simpler to just test against the
property names and directly return the correct values. This actually has
the upside that it would make it easy to lazily calculate the bbox envelope
so it's not done if the values are not required by the query. I'll look
into this as my first option.
Sampo
--
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolai...@spatineo.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc
This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
