<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 10, 2019 at 11:37 PM David Marteau <<a href="mailto:dmarteau@3liz.com">dmarteau@3liz.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> Le 10 avr. 2019 à 23:21, pblottiere <<a href="mailto:paul.blottiere@oslandia.com" target="_blank">paul.blottiere@oslandia.com</a>> a écrit :<br>
> <br>
> Hi David,<br>
> <br>
> <br>
>> If you try:<br>
>> <br>
>> request.setParameter('FOOBAR','foobar')<br>
>> <br>
>> then<br>
>> <br>
>> request.parameter('FOOBAR')<br>
>> <br>
>> then you get an empty string,<br>
>>> Even if I add an 'allowed' parameter by hand:<br>
>>> <br>
>>>> request.setParameter('FI_POINT_TOLERANCE','25')<br>
> <br>
> Actually, QgsServerRequest and QgsServerParameters are high level<br>
> classes which are not aware of valid parameters defined in services. For<br>
> example, FI_POINT_TOLERANCE is a valid parameter in WMS service, and<br>
> defined within the WMS module. But it's totally encapsulated within the<br>
> module (a shared library so), and considered as unknown from<br>
> QgsServerParameters. The only valid parameters from the<br>
> QgsServerParameters point of view are those which are common for all<br>
> services (WMS, WFS, and so on) like SERVICE, VERSION, REQUEST, ...<br>
> <br>
> If you want to retrieve the full query from the request without any<br>
> filter on valid parameters, you may use request.url(). However, I think<br>
> we could probably add a fallback on the `parameter()` method to return<br>
> invalid parameters too. I'll do a PR tomorrow and I'll ping you to check<br>
> if the behaviour suits you.<br>
> <br>
> <br>
<br>
Yes, this is what I was thinking about Looking at the code: maybe adding a lookup to the 'unmanaged' parameters if the code is not found should restore the symmetry setParameter/parameter.<br>
<br>
I'm standing from the python plugin's point of view - services and filters: plugins are expecting some behavior when setting/getting parameters. If a plugin override a parameter it can only doing it using the requestHandler which is aware<br>
only of the base QgsServerParameters owned by the QgsServerRequest instance, so they should be able to set/get parameters in a transparent way.<br>
<br>
Regards<br>
<br>
David.<br>
<br></blockquote><div><br></div><div>Hi David,</div><div><br></div><div>that makes sense, I agree completely, it's odd I didn't catch this issue before during one of my tests with plugins, I often use parameters to pass information around within plugins.</div><div><br></div><div>May I suggest that we add a test case to protect the changes when done?</div><div><br></div><div>Thanks!<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Regards,<br>
> <br>
> Paul<br>
> <br>
> <br>
> On 4/10/19 10:37 PM, David Marteau wrote:<br>
>> To add some precision:<br>
>> <br>
>> Even if I add an 'allowed' parameter by hand:<br>
>> <br>
>>> request.setParameter('FI_POINT_TOLERANCE','25')<br>
>> then<br>
>> <br>
>>> request.parameter('FI_POINT_TOLERANCE')<br>
>> return an empty string<br>
>> <br>
>>> Le 10 avr. 2019 à 19:46, David Marteau <<a href="mailto:dmarteau@3liz.com" target="_blank">dmarteau@3liz.com</a>> a écrit :<br>
>>> <br>
>>> <br>
>>> Hi devs,<br>
>>> <br>
>>> I found a strange and seemingly inconsistent behavior when accessing QgsServerRequest parameters:<br>
>>> <br>
>>> If you try:<br>
>>> <br>
>>> request.setParameter('FOOBAR','foobar')<br>
>>> <br>
>>> then<br>
>>> <br>
>>> request.parameter('FOOBAR')<br>
>>> <br>
>>> then you get an empty string,<br>
>>> <br>
>>> If you call<br>
>>> <br>
>>> request.parameters() <br>
>>> <br>
>>> Then your get a dictionary with all the values previously set.<br>
>>> <br>
>>> At first glance it seems that request.setParameter enforce use of a limited set of keys (SERVICE…..<br>
>>> <br>
>>> This does not seem very consistent with the fact parameter() should return any value previously set with setParameter and also the fact that<br>
>>> request.parameters() return all previously defined parameters key/values .<br>
>>> <br>
>>> Furthemore this may be problematic with plugins that define services in python and thus may define any other set of allowed parameters.<br>
>>> <br>
>>> Should I open an issue ?<br>
>>> <br>
>>> David<br>
> <br>
<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Alessandro Pasotti<br>w3: <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div></div>