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
