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
[QGIS-Developer] Inconsistency in QgsServerRequest parameter handling ?
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