Opened 9 years ago
Last modified 11 months ago
#26834 assigned New feature
MinValueValidator/MaxValueValidator not forwarded to form field for ModelForm
Description ¶
I just ran into a possible enhancement.
Consider the following model:
DEFAULT_RATING = 50 MAX_RATING = 100 MIN_RATING = 0 class KitReviewPropertyRating(models.Model): """ Represents properties for a kit review rated on a scale from MIN_RATING to MAX_RATING """ kit_review = models.ForeignKey('KitReview', related_name='ratings') prop = models.ForeignKey('KitReviewProperty') rating = models.PositiveSmallIntegerField( _('rating'), default=DEFAULT_RATING, validators=[MinValueValidator(MIN_RATING), MaxValueValidator(MAX_RATING)] )
and the matching ModelForm:
from django.forms.widgets import NumberInput class RangeInput(NumberInput): input_type = 'range' class KitReviePropertyRatingForm(forms.ModelForm): class Meta: model = KitReviewPropertyRating fields = ('id', 'prop', 'rating') widgets = { 'rating': RangeInput(attrs={'max': MAX_RATING}) }
As you can see, I have to specify the max
widget attribute manually, otherwise the html input looks like this: <input type="range" name="rating" value="50" min="0">
, instead of the expected <input type="range" name="rating" value="50" min="0" max="100">
. I had expected the Min/MaxValueValidator to be 'forwarded' to the form field (via IntegerField.formfield
method), but no such thing happens. #26786 does add the validators on the model level, based on the db connection used and the limits there, and only if no such validators were present yet.
I'd like to make it so that Min/MaxValueValidators are translated into min_value
/max_value
defaults for the IntegerField.formfield
method, this would be more in line with the expected output and reduce the need to repeat yourself.
According to the ticket's flags, the next step(s) to move this issue forward are:
- To improve the patch as described in the pull request review comments or on this ticket, then uncheck "Patch needs improvement".
If creating a new pull request, include a link to the pull request in the ticket comment when making that update. The usual format is:
[https://github.com/django/django/pull/#### PR]
.
Change History (11)
comment:1 by , 9 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 9 years ago
Has patch: | set |
---|
comment:4 by , 9 years ago
Version: | 1.9 → master |
---|
comment:5 by , 9 years ago
Patch needs improvement: | set |
---|
Comments for improvement on the PR (and some failing tests to be fixed).
comment:6 by , 6 years ago
Owner: | changed from | to
---|---|
Patch needs improvement: | unset |
comment:7 by , 6 years ago
Patch needs improvement: | set |
---|
comment:8 by , 4 years ago
The proposed solution has some side-effects. We should reach a wider audience and consensus on DevelopersMailingList before moving this forward.
comment:10 by , 2 years ago
Type: | Bug → New feature |
---|
comment:11 by , 11 months ago
Cc: | added |
---|
I'm wary of the additional complexity, but can't say that the request is unreasonable.