Allow input type to be optional about django-floppyforms

[brutasse]

Thanks for the report... Right now the input types problem can be avoided by passing a widget class in the form field definition:

class SomeForm(forms.Form):
    number = forms.DecimalField(widget=forms.TextInput)

Or by overriding the form's init method:

class SomeForm(forms.Form):
    number = forms.DecimalField()

    def __init__(self, *args, **kwargs):
        super(SomeForm, self).__init__(*args, **kwargs)
        self.fields['number'].widget.input_type = 'text'

There could also be a global switch in the settings but I'm not in favor of 1) introducing a floppyforms-specific setting and 2) having a different output depending on the value of a setting.

Also, the current output is HTML, not XHTML like the current behaviour in Django itself.

A decision probably needs to be made. Should floppyforms behave exactly like Django or take some distance? I agree lots of HTML5 browser controls aren't even usable now (the chrome datepicker for instance) but I found it cool to already support them. Also, if we adopt Django's current behaviour, should the "email" and "url" input types be disabled as well?

If floppyforms or a similar template-based widget system gets added to Django itself (I'll make a proposal for django 1.4), backwards compatibility becomes an issue. The fact that it's a separate library lets us take some distance, as long as this distance remains reasonable and HTML5-related issues can be solved relatively easily.

I'd rather keep the current behaviour since it's being used and documented but it's not a very strong opinion, let me know what you think...

[poswald]

I'm opening these points as issues but really I'm mostly just trying to start conversations about the design decisions. I'm definitely willing to help you get this into 1.4 as I think it is the right direction.

I think the html5 syntax is acceptable (and by this I mean using non-closing tags for example) for most developers. However, I feel like the input types trigger functionality that often may or may not be wanted on a per-field or per-application basis.

Perhaps something like:

class SomeForm(forms.Form):
    number = forms.DecimalField(input_type="text")

The issue is if you are using ModelForms. I was originally thinking of having an overridable compatibility setting put into the context and then have:

<input {% if compat %}type="{{ type }}"{% endif %} ...

I can see how that might be annoying for people who wish to modify the templates. Another option would be to set the type in the widget class based on the setting. I can see it coming up as an issue for people so perhaps the solution is to simply document it.

[brutasse]

I agree with you about the input type thing but I'd really love not to introduce complexity that would get in the way of people willing to have the "new" input types.

In django there is a clear separation between a form field (handling data validation and coercing) and a form widget (rendering an <input> with the value in it). The syntax you're suggesting (DecimalField(input_type="text") would introduce a coupling between the fields and the widgets API. Plus, we're already messing with widgets rendering so I'd love not to mess with the fields API :).

I'm not sure what you mean by "the issue is if you are using ModelForms".

For a start I'll add a section to the docs: "I'm already using django forms, what happens exactly if I switch to floppyforms?". There could be a detailed description of the differences and we can document how to get strictly django's behaviour. I'll try to give it a go this week.

[brutasse]

I finally added that section. If you see anything that can be improved, let me know!

http://django-floppyforms.readthedocs.org/en/latest/differences.html

(not sure what to do with the issue though :)

[poswald]

I think that definitely helps. I'll close this issue. If either of us come up with a better way to switch the forms fields on a case by case basis, we can revisit it. Thank you!

[brutasse]

I'm definitely considering the addition of a formfield_callback [0] for a floppyforms-flavoured ModelForm. I'd rather enabled it directly in the default ModelForm for consistency, this way you get only floppyforms with no extra syntax and not a mix of different libraries.

[0] http://stackoverflow.com/questions/660929/how-do-you-change-the-default-widget-for-all-django-date-fields-in-a-modelform