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
> - 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
Cheers
Andrea
--
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
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
