You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, when using multiple colander-based validators simultaneously (i.e.: validators=[colander_path_validator, colander_querystring_validator, colander_header_validator], I get some weird behavior where each validator seems to consider that specified schema is only representing their own sub-location rather than the full "request" as in the case of colander_validator, leading to response errors:
{
"status": "error",
"errors": [
{
"location": "path",
"name": "path",
"description": "Missing value for required field without any default."
},
{
"location": "path",
"name": "header",
"description": "Missing value for required field without any default."
},
{
"location": "path",
"name": "querystring",
"description": "Missing value for required field without any default."
},
{
"location": "path",
"name": "path",
"description": "Missing value for required field without any default."
},
{
"location": "path",
"name": "header",
"description": "Missing value for required field without any default."
},
{
"location": "path",
"name": "querystring",
"description": "Missing value for required field without any default."
}
]
}
My specific use case is that I have a single view that can handle 2 distinct content-type simultaneously. Therefore, it is decorated with distinct schema references for the corresponding content-type representation, but I must explicitly ignore the "headers" validator, otherwise both fail against the opposite definition (not sure why they are not handled automatically by the appropriate renderer and/or accept, but maybe this another issue...). Anyway, this leads to a definition similar to the following:
Is the above the correct use? So far, I have used multi-decorator service/views for a while (to support redirects or otherwise "compatible" URI for similar contents), and they seemed to work correctly and as intended.
My only recent addition is the validators, and I would like to know if the list approach is valid.
It seems listing validators is supported after looking at the code, but maybe the use of multiple colander_[...]_validator is not supported?
What would be the alternative?
The text was updated successfully, but these errors were encountered:
When using
Everything seems to work as expected.
However, when using multiple
colander
-based validators simultaneously (i.e.:validators=[colander_path_validator, colander_querystring_validator, colander_header_validator]
, I get some weird behavior where each validator seems to consider that specifiedschema
is only representing their own sub-location rather than the full "request" as in the case ofcolander_validator
, leading to response errors:My specific use case is that I have a single view that can handle 2 distinct content-type simultaneously. Therefore, it is decorated with distinct schema references for the corresponding content-type representation, but I must explicitly ignore the "headers" validator, otherwise both fail against the opposite definition (not sure why they are not handled automatically by the appropriate
renderer
and/oraccept
, but maybe this another issue...). Anyway, this leads to a definition similar to the following:Is the above the correct use? So far, I have used multi-decorator service/views for a while (to support redirects or otherwise "compatible" URI for similar contents), and they seemed to work correctly and as intended.
My only recent addition is the
validators
, and I would like to know if the list approach is valid.It seems listing validators is supported after looking at the code, but maybe the use of multiple
colander_[...]_validator
is not supported?What would be the alternative?
The text was updated successfully, but these errors were encountered: