[OpenLayers-Trac] Re: [OpenLayers] #2956: script protocol for reading features cross-origin

[OpenLayers]

#2956: script protocol for reading features cross-origin
----------------------+-----------------------------------------------------
 Reporter:  tschaub   |       Owner:  fredj       
     Type:  feature   |      Status:  new         
 Priority:  minor     |   Milestone:  2.11 Release
Component:  Protocol  |     Version:  2.10        
 Keywords:            |       State:  Review      
----------------------+-----------------------------------------------------

Comment(by tschaub):

 Thanks for adding tests to this.  I'll say I'm not that fond of the
 {{{FilterSerializer}}}.  I do like that this patch takes all that specific
 filter serialization out of the HTTP protocol, but I don't think it
 necessarily makes it any more configurable.  It would be nice if the app
 dev could provide their own filterToParams method.  With this change, if
 {{{OpenLayers.Protocol.FilterSerializer}}} is loaded, it will clobber any
 custom {{{filterToParams}}} method.

 {{{OpenLayers.Protocol.FilterSerializer}}} is a pretty generic name for a
 very specific convention for serializing filters.  Is this convention
 unique to MapFish, or did it comes from elsewhere?

 At a minimum, the script protocol should call initialize on the super
 after extending itself with the {{{filterToParams}}} (and
 {{{regex2value}}}) method from the mixin.  I think I'd like it even better
 if that custom {{{filterToParams}}} method were assigned a more suitable
 name (e.g. a single {{{OpenLayers.Protocol.mapFishFilterSerializer}}}
 method would do the trick and you could configure your custom protocols to
 use it for {{{filterToParams}}}).

 In case it is not obvious what I mean by the specific {{{filterToParams}}}
 method, I can also imagine methods that would serialize as
 [http://www.opengeospatial.org/standards/cat CQL] or
 [http://www.opengeospatial.org/standards/cat ECQL] or following the
 [http://code.google.com/apis/gdata/docs/2.0/reference.html#FieldConditions
 GDATA guide for field conditions] (though I think their
 [http://code.google.com/apis/analytics/docs/gdata/gdataReferenceDataFeed.html#filterSyntax
 filter syntax for Analytics Feeds] would be more relevant) or
 [http://developer.yahoo.com/yql/guide/filters.html any] of
 [http://code.google.com/appengine/docs/python/datastore/gqlreference.html
 the others] who have riffed on WHERE clauses from SQL.

 In short, why the custom query syntax baked into OpenLayers?

 (PS - Hope this doesn't sound overly harsh.  I think it will be great to
 get this Script protocol in.  The specific {{{filterToParams}}} bit has
 just puzzled me for a while.)

-- 
Ticket URL: <http://trac.openlayers.org/ticket/2956#comment:4>
OpenLayers <http://openlayers.org/>
A free AJAX map viewer