Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#30306 closed Cleanup/optimization (invalid)

Textarea widget missing input_type

Reported by: minusf Owned by: nobody
Component: Forms Version: 2.2
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no


(I tried to search for this both in here and the pull requests on github but there is an eerie quiet about it.)

Textarea seems to be one of the few (if not the only) widget not defining input_type.
I can't think of a good reason why it couldn't have one and some people find out about this strange omission when they try to do something like:

        for field in self.fields:
            widget = self.fields[field].widget

            if widget.input_type == "select":
            elif widget.input_type == "checkbox":

but end up with:

AttributeError: 'Textarea' object has no attribute 'input_type'

Change History (4)

comment:1 by Tim Graham, 5 years ago

Resolution: invalid
Status: newclosed
Type: UncategorizedCleanup/optimization

What would a sensible value be? It doesn't seem applicable to me. The code in question should use if hasattr(widget, 'input_type') as Django does.

comment:2 by minusf, 5 years ago

Closed already? I think this is a fair bit of inconsistency and I would welcome at least some discussion.

This is not just about not triggering an exception. This is about having a useful way to identify widget types.
So textareas are the widgets that have no input_type? This makes programmatic widget customisation painful.

As for the value, what's wrong with 'textarea' ? Select has select, checkbox has checkbox, etc. Even hidden has one.
Why should textarea be different?

class Input(Widget):
    Base class for all <input> widgets.
    input_type = None  # Subclasses must define this.             <================= my emphasis
    template_name = 'django/forms/widgets/input.html'

While this comment is in Input and not Widget (and Textarea inherits from Widget) the intention and philosophy seems clear to me.

comment:3 by Tim Graham, 5 years ago

For Input subclasses, input_type corresponds to <input type="...">. ChoiceWidget uses input_type for a different purpose.

comment:4 by minusf, 5 years ago

I understand that the "abstraction" is leaking. But Select and RadioSelect both have input_type, even if for a "different purpose", those can be used in the same way as input_type for "true" Input widgets... It's not ideal, but it's already there and only Textarea is left out in the cold. The other alternative could be to add widget_type or such to every Widget subclass but at this point it would just duplicate input_type.

Note: See TracTickets for help on using tickets.
Back to Top