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?
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 multiplecolander_[...]_validator
is not supported? What would be the alternative?