On Sat, Apr 2, 2016 at 10:44 AM, Florian Apolloner
wrote:
> Yeah, I am also mostly worried about this. formfield for me is a quick
> shortcut, if you want to customize it, do it at the form level imo.
Does this mean we can close #26369 ?
--
You received this message because you are subscribed t
On Thursday, March 17, 2016 at 2:17:40 PM UTC+1, Tim Graham wrote:
>
> It seems useful, but I'm not sure if it increases the coupling between
> model and forms in an undesirable way?
>
Yeah, I am also mostly worried about this. formfield for me is a quick
shortcut, if you want to customize it,
Yes, overriding the model field to change the definition of
formfield() works. It is indeed possible to define two model field
classes which have different formfield() methods, for example:
ManyToManyCheckboxField()
ForeignKeyRadioField()
Should Django provide such fields ?
formfield_callback is
I'm not sure whether or not to accept a related proposal to add a
"formfield_defaults" keyword to model fields [0]. e.g.
link = models.OneToOneField(
...
formfield_defaults={
'widget': forms.RadioSelect,
}
)
It seems useful, but I'm not sure if it increases the coupling betw
If we prefer to remove form related stuff from models, then we should
be able to register new default model forms:
models.py:
class YourModel(models.Model):
your_field = models.BooleanField()
forms.py:
class YourModelDefaultForm(django.?.ModelFormConfiguration):
class Meta:
help
On Thu, Mar 17, 2016 at 2:17 PM, Tim Graham wrote:
> It seems useful, but I'm not sure if it increases the coupling between model
> and forms in an undesirable way?
The coupling is already there because model fields sit right
in-between the db and form fields, so I don't know if it would
actually
What I meant about increasing coupling is this question: do we want to go
down the road of defining more and more form related things in models? Yes,
there are already a few options that are primarily for model forms (e.g.
editable and blank), but is it okay to add more or should we try to avoid
A few thoughts, just to see if we can solve the problem by documenting some
existing code:
Would making a subclass overriding formfield() work?
class RadioSelectBoolean(models.BooleanField):
def formfield(self, *args, **kwargs):
kwargs['widget'] = forms.RadioSelect
super(Radio
I got that, but you can't just make it your default widget, it will always
require more information. And I don't really like "defaults", again pep20.
I currently don't have any need for action, therefore I won't do anything. If
you want to make a draft on how to refactor it, I'm happy to rev
I just meant that currently, if a user wants to make Select2 the
default widget for a model field, it is necessary to subclass the
modelfield class and override the model field's formfield() method
just to change the default widget it uses, sorry if it wasn't clear !
--
You received this message
Regarding django-select2:
I don’t want to provide fields at this point. Django has the concept of
widgets, and that is all I need for select2.
You could overwrite the widget for all forms with a template processor, but
why? You’d need to know which db columns you need too search to fil
On Wed, Mar 9, 2016 at 3:09 PM, Johannes Hoppe wrote:
> We'll you can change the `default` form Field using
> `django.db.models.Field.formfield`.
Do you mean that, for example, an app like django-select2 could
provide the following model fields ?
- Select2WidgetForeignKey,
- Select2WidgetOneToOn
We'll you can change the `default` form Field using
`django.db.models.Field.formfield`.
But that is actually the thing I don't like I think this needs to go: https://
github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/
db/models/fields/__init__.py#L869-L905
But at t
Hi !
Currently, by default, django's ModelForm uses form fields which are
known to be compatible for the modelfield.
By "compatible", I mean that it works when the ModelForm calls:
- ModelField.value_from_object() to get the initial formfield value
for the model's field, via model_to_dict:
https
Hi Tim, and I guess that's you James?
Thanks for pointing me towards this discussion. Tho I do like the idea for
the sake of `django-select2`, I think it's a bad idea for Django.
I don't think that `django.db` should be even aware of `django.forms`. I
don't even like the current implementation t
Thanks Tim. Something like that would work, perhaps the first step
would be to make modelfield.formfield a bit more configurable ?
Currently, the default form field class for a model field is hardcoded
in the model field's formfield() method, ie:
https://github.com/django/django/blob/master/django
One idea (and it could be a terrible one) after a few minutes of thinking
about it is an API similar to the query lookup/tranform API where you could
write something like:
from django.db import models
models.CharField.register_formfield(MyCustomFormField)
which would make all subsequent CharFie
Hi all,
Currently, the model field defines the default form field that's used
by the modelform metaclass. It would be nice if an external app could
overwrite this.
For example, a user installs an app which provides a more elaborated
relation select field. They configure the app to be able provide
18 matches
Mail list logo
