Zope
Zope copied to clipboard
Argument conversion, add a :json converter
In a HTML template, we use an attribute data-filters where value is json :
<a href="#" data-filters:json="{'to_print': true}" >
This is used by a JS code that pass it it a view thru an ajax call.
This result in a call like http://.../@@my_view?filters:json={"to_print":true}
What I expect to happen:
In the __call__ method of @@my_view, I expected the filters argument to have been auto-magically converted to python, like it is the case when argument are suffixed with int or boolean.
What actually happened:
I get a string representation of the json value, I need to json.load the value.
What version of Python and Zope/Addons I am using:
This happen with Zope2/Py2.7 (Plone 4.3.x) and Zope4/Py3.8 (Plone 5.2.x)
This was discussed here : https://community.plone.org/t/zope-publisher-converter-for-json-like-it-exists-for-int/13586
What I actually would like to know is if I propose a PR for this, that would be merged? As json is not really a type...
We already added a converter here : https://github.com/IMIO/imio.helpers/blob/master/src/imio/helpers/converters.py and it works, just wondered if it could get into ZPublisher...
Thank you!
Gauthier
+1 from me! Please also write a test for new code.
As json is not really a type..
When you have a look at the following list, the name type does not fit anyway... no worries about that.
https://github.com/zopefoundation/Zope/blob/25119a5ac7f783b7f59cd3dcaf2519676abeee65/src/ZPublisher/Converters.py#L226-L243
Gauthier Bastien wrote at 2021-3-31 06:12 -0700:
In a HTML template, we use an attribute data-filters where value is json :
<a href="#" data-filters:json="{'to_print': true}" >This is used by a JS code that pass it it a view thru an ajax call.
This result in a call like
http://.../@@my_view?filters:json={"to_print":true}What I expect to happen:
In the
__call__method of@@my_view, I expected thefiltersargument to have been auto-magically converted to python, like it is the case when argument are suffixed withintorboolean.
I implemented something like this in dm.zopepatches.ztutils
via a general extension mechanism for ZPublisher's converters
and ZTUtils complex_marshal (which is used for its make_query
and make_hidden_input).
-- Dieter
Putting that general extension mechanism for ZPublisher converters would be my preferred solution as well, then everyone can register their own more easily or publish add-ons that contain such registrations and their implementation.
While a general extension mechanism would be really great, I still think JSON is a common enough format to be supported in Zope core.
There is always the question who has the time and knowledge and is willing to spend it for the more elaborate solutions.
Creating the registration mechanism is a matter of adding one single function as a clean entry point for adding converters. Even that isn't strictly necessary because as the OP proves at https://github.com/IMIO/imio.helpers/blob/master/src/imio/helpers/converters.py you can simply import the type_converters structure and mutate it directly. I don't see any complexity there. I'd rather do that then adding arbitrary converters. I see more issues with time and knowledge missing to support those arbitrary converters added by contributors.
Hi @jugmac00 @dataflake @d-maurer
thank you for feedback!
So finally what should be done here?! ;)
I think I will propose a PR adding the json converter like it exists for other "types" and we will see, this isn't so much work...
I looked at the code of dm.zopepatches.zutils, maybe this should go back to zope core at some point?
Gauthier
I added it to Friday's sprint agenda, and I will try to come up with an answer afterwards.
I'd rather do that then adding arbitrary converters. I see more issues with time and knowledge missing to support those arbitrary converters added by contributors.
@dataflake I agree with your point on arbitrary converters.
OTOH, I am of the opinion that enabling Zope to use one of the batteries included by Python (to be precise json) makes total sense, especially if it only demands 10 lines of code. Which does not require a lot of time and knowledge as it delegates the work to the standard library.
Now, I am maybe not deep enough and you saw issues that I missed in those 10 lines.
So finally what should be done here?! ;)
Please go ahead and create a PR, this feature ist interesting and should not be a huge maintenance burden.
Fixed by #1066