Re: [QGIS-Developer] Inconsistency in QgsServerRequest parameter handling ?
On Wed, Apr 10, 2019 at 11:37 PM David Marteau wrote:
>
> > Le 10 avr. 2019 à 23:21, pblottiere 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.
>
>
Hi David,
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.
May I suggest that we add a test case to protect the changes when done?
Thanks!
> > 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 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
--
Alessandro Pasotti
w3: www.itopen.it
___
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
Re: [QGIS-Developer] Inconsistency in QgsServerRequest parameter handling ?
> Le 10 avr. 2019 à 23:21, pblottiere 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 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
Re: [QGIS-Developer] Inconsistency in QgsServerRequest parameter handling ?
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.
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 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
Re: [QGIS-Developer] Inconsistency in QgsServerRequest parameter handling ?
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 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
