Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default setter needs to know the field name #279

Open
pvanderlinden opened this issue Nov 3, 2016 · 3 comments
Open

Default setter needs to know the field name #279

pvanderlinden opened this issue Nov 3, 2016 · 3 comments
Milestone

Comments

@pvanderlinden
Copy link

pvanderlinden commented Nov 3, 2016

It would be very usefull to let the default setter know which field it is.
Use case:

  • a filter can only have values which depends on the logged in user
  • if the filter is missing it should default to all the values the user is allowed to pass in

Currently I work around this issue by having the default setter set it to '__all__' and then in the custom validator (which also validates the allowed values), and let it expand to actual default in self.document. Which might break in feature versions.

@marcpearson
Copy link

Since the field was mandatory in my custom _validate_type_string and _validate_type_date functions, i modify the validator class too. Please leave the field name in the parameters or set a way to get the current processed field name from the Validator class

@funkyfuture
Copy link
Member

what about the following design: the callables' signatures are inspected before calling and provided with the parameters as needed. like pytest is injecting fixtures to test functionns.

@funkyfuture funkyfuture changed the title [Feature Request] Default setter needs to know the field name Default setter needs to know the field name Jun 2, 2018
@funkyfuture
Copy link
Member

so, the idea of dependency injection that allows custom signatures is included in the roadmap for the next major release. it will take a while 'til the journey gets there, and this feature has a rather high potential to conflict with the desire to not break too much with a major release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants