Brian Beck wrote:
> I think your model_field helper being built-in (short for
> x._meta.get_field(y).formfield(**params), which is not very pretty)
> would be the best solution here. In my experience, customizing just
> the widget for a model field is just as common as changing just the
> label,
SmileyChris wrote:
> I do feel like it leads to slippery slope though. LikeMichael said,
> "why stop at widgets?" I often need to change labels and help text
> too.
Full customization already can be done by specifying fields directly in
a form class. In my experience widgets are just very
On Sep 29, 11:40 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote:
>
> > Why not do something like this:
>
> > class MyForm(forms.ModelForm):
> > class Meta:
> > fields = {
> > 'text':
On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote:
> Why not do something like this:
>
> class MyForm(forms.ModelForm):
> class Meta:
> fields = {
> 'text': forms.CharField(widget=forms.Textarea(), ...),
> 'other_field': None,
> }
This syntax would
I understand the motivation for this, and support the idea, but I
think the implementation is a little repetitive:
class MyForm(forms.ModelForm):
class Meta:
fields = # LIST OF FIELDS
widgets = # DICT OF FIELD NAMES : WIDGETS
Why not do something like this:
class
Bah, it was just prototype code but point taken ;)
I do feel like it leads to slippery slope though. LikeMichael said,
"why stop at widgets?" I often need to change labels and help text
too.
On Sep 29, 8:56 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> SmileyChris wrote:
> > I've always just
SmileyChris wrote:
> I've always just done this by doing:
>
> MyForm(ModelForm)
> model = MyModel
> def __init__(self, *args, **kwargs):
> self.fields['name'].widget = Textarea() # or whatever
You've forgot to call `super` :-). I know that it's only an example but
it adds
On Sep 28, 1:13 am, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Joseph Kocherhans wrote:
> > On Sun, Jul 6, 2008 at 6:27 AM, Ivan Sagalaev
> > <[EMAIL PROTECTED]> wrote:
> >> ## Proposal
>
> >> To fix this I was thinking along the lines of:
>
> >> class ArticleForm(ModelForm):
> >>
Joseph Kocherhans wrote:
> On Sun, Jul 6, 2008 at 6:27 AM, Ivan Sagalaev
> <[EMAIL PROTECTED]> wrote:
>> ## Proposal
>>
>> To fix this I was thinking along the lines of:
>>
>> class ArticleForm(ModelForm):
>> class Meta:
>> model = Article
>> fields =
Michael Elsdörfer wrote:
> Why stop at widgets?
Basically, because I was struggling with widgets many times but didn't
have any practical needs for changing a label, for example. I don't say
it's useless or something but I just can't defend it from my experience.
> By the way, IIRC the
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
> widgets = {
> 'text': Textarea(...),
> }
Why stop at widgets? Let's say I want to change just the label of a
field,
On Sun, Jul 6, 2008 at 8:44 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
> As for dynamic choices, I think that still belongs to the init method,
> not the Meta class.
No, I mean kinda dynamic_FIELD_choices methods, as it was suggested
for ModelAdmin.
> On Jul 6, 11:20 pm, Ivan Sagalaev <[EMAIL
To add to the case, redefining fields in ModelForm can introduce
serious problems and do more than just compromise DRY.
E.g. if you have a model field that's optional (blank=True), you need
not to forget to add 'required=False' to your form field re-
declaration...
As for dynamic choices, I
Hi Ivan,
1) You missed making a subclass as third option in your initial post
(and preferred one), that's why i suggested it.
2) "Sure everyone can subclass anything or patch Django installation"
is not much realistic statement: for some things, it's much easier
than for other ;)
3) Why I think
Yuri Baburov wrote:
> And before it's landed into the trunk (i hope it will ;) ) you can
> make your own subclass of ModelForm which does exactly what you
> proposed, and then subclass it everywhere ;)
Yuri, it's a bit redundant note :-). Sure everyone can subclass anything
or patch Django
Hi Ivan,
Yes, together with dynamic choices will perform great (on init,
developers might assign some options to widgets...).
And before it's landed into the trunk (i hope it will ;) ) you can
make your own subclass of ModelForm which does exactly what you
proposed, and then subclass it
> ## Proposal
>
> To fix this I was thinking along the lines of:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
> widgets = {
> 'text': Textarea(...),
> }
>
> Sound
Steve Holden wrote:
> What's CSS for?
For styling. Choosing widgets has nothing to do with styling. My cols
and rows for textarea is just an example that, incidently, can be
emulated with CSS. But often you want to use a different widget
altogether, say, a set of radio buttons instead of
Ivan Sagalaev wrote:
> Hi, everyone!
>
> I was recently refactoring some old code to use a ModelForm and was
> stuck at an issue that we don't have a simple way to say "this form has
> these fields from a model but with other widgets".
>
> For example I have an Article model that I want to
Hi, everyone!
I was recently refactoring some old code to use a ModelForm and was
stuck at an issue that we don't have a simple way to say "this form has
these fields from a model but with other widgets".
For example I have an Article model that I want to edit in a form:
class
20 matches
Mail list logo
