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