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
> d...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev

_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev

Reply via email to