feat: Pass field names to Validators and Constraints #263
Conversation
This change allows Constraints to access the field name they're validating, enabling more descriptive and context-aware error messages. This is particularly useful for custom constraints that need to provide field-specific validation messages. Key changes: - Pass field name from Schema._validate_item to Validator - Add field_name property to Validator and Constraint classes - Propagate field name through validation chain - Update documentation with examples
README.md
Outdated
| @@ -446,6 +446,38 @@ Validates included structures. Must supply the name of a valid include. | |||
| Examples: | |||
| - `include('person')` | |||
|
|
|||
| ### Field Names in Constraints | |||
| Constraints can now access the field name they're validating, enabling more descriptive error messages. This is particularly useful for custom constraints that need to provide field-specific messages. | |||
There was a problem hiding this comment.
Consider changing to "Constraints can access the field name they're validating, enabling descriptive error messages". Removes the words "now" and "more".
Since this is a README, the text should indicate the feature has always been there....this text will be there for the next 10 years. :)
| @@ -13,6 +13,8 @@ class Constraint(object): | |||
| is_active = False | |||
|
|
|||
| def __init__(self, value_type, kwargs): | |||
| self.field_name = None # Added for custom field-aware messages | |||
| self.value_type = value_type # Added for custom type-aware messages | |||
There was a problem hiding this comment.
Consider creating a test for value_type.
|
When I ran the tests, I got errors similar to the following: Did you get these errors when running the tests? Unfortunately, not all validators are of the |
|
@mildebrandt, thanks for the review. Updated PR with your suggestions. Test suite wasn't properly setup on my end before creating the PR. Tests ran without errors for me now. |
nbaju1
force-pushed
the
feat/pass-field-names
branch
from
ebf0e66 to
65963a5
Compare
README.md
Outdated
| @@ -446,6 +446,38 @@ Validates included structures. Must supply the name of a valid include. | |||
| Examples: | |||
| - `include('person')` | |||
|
|
|||
| ### Field Names in Constraints | |||
There was a problem hiding this comment.
I don't think there's a case where we can have a custom constraint without a custom validator....so I think moving this under the Custom Validators section may be better. Please move it down and indent the heading by one...so 4 # signs.
|
I think this looks good. But I have no power here anymore. :) Someone from the team will want to review and decide if it's a feature that they want to include in Yamale. |
|
@cblakkan, did you get a chance to look at this? |
|
I like the "deprecated" flag idea, but it would be more informative if it could be a message, not just a boolean value. |
I've been busy and haven't had a chance to dig into this yet but this was suggested to me by @joecackler and if done this way you would just need to write your own
One of the things I was going to dig into was how helpful the change might be in improving the existing validation error messages. Though if we do pass field_name and value_type to the Constraint it seems like it should be passed via the |
This PR adds the ability for Validators and Constraints to access the field name they're validating. This enables more descriptive error messages and warnings that can reference the specific field being validated.
Changes
field_nameproperty toValidatorandConstraintclassesUse Case
This is particularly useful for constraints that need to reference the field name in their messages, such as deprecation warnings or field-specific validation errors.