> Le 10 avr. 2019 à 23:21, pblottiere <paul.blotti...@oslandia.com> a écrit :
>
> Hi David,
>
>
>> If you try:
>>
>> request.setParameter('FOOBAR','foobar')
>>
>> then
>>
>> request.parameter('FOOBAR')
>>
>> then you get an empty string,
>>> Even if I add an 'allowed' parameter by hand:
>>>
>>>> request.setParameter('FI_POINT_TOLERANCE','25')
>
> Actually, QgsServerRequest and QgsServerParameters are high level
> classes which are not aware of valid parameters defined in services. For
> example, FI_POINT_TOLERANCE is a valid parameter in WMS service, and
> defined within the WMS module. But it's totally encapsulated within the
> module (a shared library so), and considered as unknown from
> QgsServerParameters. The only valid parameters from the
> QgsServerParameters point of view are those which are common for all
> services (WMS, WFS, and so on) like SERVICE, VERSION, REQUEST, ...
>
> If you want to retrieve the full query from the request without any
> filter on valid parameters, you may use request.url(). However, I think
> we could probably add a fallback on the `parameter()` method to return
> invalid parameters too. I'll do a PR tomorrow and I'll ping you to check
> if the behaviour suits you.
>
>
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.
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
only of the base QgsServerParameters owned by the QgsServerRequest instance,
so they should be able to set/get parameters in a transparent way.
Regards
David.
> Regards,
>
> Paul
>
>
> On 4/10/19 10:37 PM, David Marteau wrote:
>> To add some precision:
>>
>> Even if I add an 'allowed' parameter by hand:
>>
>>> request.setParameter('FI_POINT_TOLERANCE','25')
>> then
>>
>>> request.parameter('FI_POINT_TOLERANCE')
>> return an empty string
>>
>>> Le 10 avr. 2019 à 19:46, David Marteau <dmart...@3liz.com> a écrit :
>>>
>>>
>>> Hi devs,
>>>
>>> I found a strange and seemingly inconsistent behavior when accessing
>>> QgsServerRequest parameters:
>>>
>>> If you try:
>>>
>>> request.setParameter('FOOBAR','foobar')
>>>
>>> then
>>>
>>> request.parameter('FOOBAR')
>>>
>>> then you get an empty string,
>>>
>>> If you call
>>>
>>> request.parameters()
>>>
>>> Then your get a dictionary with all the values previously set.
>>>
>>> At first glance it seems that request.setParameter enforce use of a limited
>>> set of keys (SERVICE…..
>>>
>>> This does not seem very consistent with the fact parameter() should return
>>> any value previously set with setParameter and also the fact that
>>> request.parameters() return all previously defined parameters key/values .
>>>
>>> Furthemore this may be problematic with plugins that define services in
>>> python and thus may define any other set of allowed parameters.
>>>
>>> Should I open an issue ?
>>>
>>> David
>
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
