Adding FORM_PART_LIMIT for overriding MultipartParser.part_limit#1251
Adding FORM_PART_LIMIT for overriding MultipartParser.part_limit#1251
Conversation
|
I think that's a good idea but not ready for merging. This needs tests and it should be configurable in zope.conf under the |
|
@drfho I'm currently working on making this configurable. Question: I'm not a frontend developer so I don't know how big those forms can get. Would it not be better to choose a lower default (or even the |
128 is really low; 512 would be good and 1024 quite safe. I think the authors of multiparts are not adressing production GUIs but 3rd view front-ends that are published to the public. Supposingly they didn't have administrative GUIs like Zope, Plone etc in mind. |
Yes you're right, I didn't think about mile long folder contents lists in the ZMI. |
|
And the grid of checkboxes in manage_access... |
|
ok, looks perfect, many thanks! |
|
No, it is done by the person who opened the PR, unless this is an unknown new developer. |
Complex modelling GUIs may have lot of form values in a grid. With the introduction of multipart==1.2.1
https://github.com/zopefoundation/Zope/blame/a2cbf86fca81836aac194b1075ed0728e8c0c79b/requirements-full.txt#L27
some weeks ago the arbitrary limit of 128 form parameters is getting relevant. Using the new requirement ZPublisher blocks bigger forms. I would like to suggest handling the parts_limit it similar to the other form limits and add a corresponding variable
that can override the 128 limitation.
Ref: zms-publishing/ZMS#334