getFeature request sent twice

[pgiraud]

When clicking on the map, the getFeature request is sent twice.  http://www.openlayers.org/dev/examples/getfeature-wfs.html

It seems like it is a regression compared to  http://dev.openlayers.org/releases/OpenLayers-2.8/examples/getfeature-wfs.html

By the way, Control.GetFeature is missing in the components list.

[ahocevar]

This is caused by the Box handler, which now also fires when you don't drag a box. The above patch fixes the issue and tests still pass, but I have only tested on Firefox 3.6.

[ahocevar]

a better fix, because it uses the click handler if click is set to true

[pgiraud]

Hey ! Once again we had a great discussion on this with Eric. It doesn't seem so easy to fix this issue. Actually, in 2.8 we weren't supporting the "Box is so small that it can be considered as point" and this case was handled by the selectSingle method if click was set to true. However, the selectSingle returns only one feature where the selectBox can return several features even if the box is a simple point. Nowadays, the request is sent twice to the server, but the two responses are possibly read in different ways, may give different results.

In my opinion, none of the proposed patches will solve the problem until we explicitly explain (in doc comments) that one handler takes the precedence on the other. In my mind, if the user sets box to true, he assumes that he can be answered several features from the server. The application is probably already supporting "multi-features responses". I think that the box handler can take precedence. So I prefer the first patch.

[bartvde]

fredj, but that would be a change from 2.8, and would need an option which by default is false IMHO.

[bartvde]

Replying to bartvde:

fredj, but that would be a change from 2.8, and would need an option which by default is false IMHO.

I meant pgiraud, sorry :-)

[ahocevar]

Ok, so someone tell me what to do. From the above discussion, it seems reasonable to commit the 2nd patch and add some explanation to the API docs, right?

[bartvde]

Pierre is suggesting using your first patch, but personally I am against this since this changes behaviour from 2.8. Andreas, I am okay with your suggestion (committing patch 2 and adding explanation to the API docs). If Pierre really wants to have an option to have the box handler handle the click case, I suggest opening up a new enhancement bug in the 2.10 milestone.

[ahocevar]

Same as the previous patch, but with api docs explaining the behavior when both click and box are set to true

[ahocevar]

Waiting for "Commit" state if you think that the new patch explains what is going on.

[bartvde]

Looks good, I might leave out the part "(i.e. a single feature)" since to me it is a bit confusing, but I'll leave that decision op to you. Thanks for your work on this.

[ahocevar]

(In [10215]) Avoid duplicate feature requests for clicks, and make clear that the click handler takes precedence over the box handler. r=bartvde,pgiraud (pullup #2581)

[ahocevar]

(In [10216]) Fixed typo. Non-functional change (see #2581)

[bartvde]

Pulled up into the 2.9 branch in r10218