Good to know Chris. Thanks for the reply. I did check the Feature
Server docs to see if this filter syntax was used there as well. Guess
I didn't dig enough.
I agree that it deserves a better name if used more widely. Since it is
the default for the HTTP protocol, we could call it simply
httpFilterSerializer or olFilterSerializer.
I'm happy to make the changes if anybody else has suggestions.
Tim
On 1/27/11 2:15 PM, [email protected] wrote:
Tim,
MapFish and FeatureServer use essentially the same filter parameters, and at the
time, when we discussed it on the mailing list, it seemed a simple enough
convention
that backing it into HTTP (to be subclassed/replaced by higher level protocols)
wasn't a big deal.
I'm not aware of anyone actively using Filters with FeatureServer, so I have no
investment in keeping it the way it is, but I do think that tying it to MapFish
is a bit narrow; I don't have a better suggestion at the moment.
-- Chris
On Jan 27, 2011, at 4:03 PM, ext Tim Schaub wrote:
Hey-
I posted a link a while ago to a working Script protocol for reading features
cross-origin.
http://dev.openlayers.org/sandbox/tschaub/xdomain/examples/cross-origin.html
Pierre jumped in and helped out by writing tests (thanks for that). The other
changes he made prompted a question for me about the filterToParams method in
the HTTP protocol (something that has nagged me for a while actually).
Summarized here: http://trac.osgeo.org/openlayers/ticket/2956#comment:4
Basically, I think we should not go too far with this custom method of
serializing a filter in a query string. I'm pretty sure this is a MapFish
specific convention (but could be wrong about that).
I also think it makes sense to let app devs provide their own simple
filterToParams methods (I've done this in the updated cross-origin.html
example).
Further, I think we could provide additional conventions for serializing
filters in the library. I think it would make sense to support CQL/ECQL for
example. I also think we could have a simple Open Search (with Geo extension)
filter serializer. All of these should be named like the conventions or
standards they represent.
Following this, I think it makes sense to name the current filterToParams
method what it is. I've proposed OpenLayers.Protocol.mapFishFilterSerializer
in this ticket:
http://trac.osgeo.org/openlayers/ticket/3032
Thanks for any feedback,
Tim
PS - The updated Script protocol ticket is also review-ready:
http://trac.osgeo.org/openlayers/ticket/2956
--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.
_______________________________________________
Dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.
_______________________________________________
Dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
