[OpenLayers-Trac] Re: [OpenLayers] #3237: Issue with filter params in Protocol/HTTP.js

[OpenLayers]

#3237: Issue with filter params in Protocol/HTTP.js
----------------------------------+-----------------------------------------
 Reporter:  etdube                |       Owner:              
     Type:  bug                   |      Status:  new         
 Priority:  minor                 |   Milestone:  2.11 Release
Component:  Protocol.HTTP         |     Version:  SVN         
 Keywords:  filter http protocol  |       State:  Review      
----------------------------------+-----------------------------------------

Comment(by etdube):

 Thanks Eric for the review.

 The root cause of the issue is that the following line:

 {{{
 options = OpenLayers.Util.applyDefaults(options, this.options);
 }}}

 ... assigns this.options.params to options.params (i.e. in the options
 object that is passed as an argument to read() ) when options.params is
 undefined. This means that any further change to options.params does
 effectively modify this.option.params when it's not supposed to, so your
 understanding is right. This also means the second call to read() in the
 test has a side effect of assigning this.options.param to the options
 object passed to read() (i.e. opt2), therefore opt2.params will contain
 leftover stuff (i.e. the {{{foo__eq}}} filter param) from the first call
 that shouldn't be there. Hence the test does verify what the correct
 behavior should be; however if you feel that doing the assertion against
 protocol.options.params is clearer, you could replace the line by:

 {{{
 t.eq(protocol.options.params["foo__eq"], undefined, "[options.params]
 first filter should not be in protocol.options.params");
 }}}

 ... or even remove the 2nd call to read() and simply do this assertion
 after the 1st call.

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