Re: Declarative syntax for widgets in ModelForm
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, just the help text, or just the 'required' status. Using your > helper one could override any number of these, the rest being taken > from the defaults. May be... I just don't like how it looks. Apart from repeating model name for each field and field's own name twice it is not as readable as a couple of params in Meta that clearly show in what the form is different from default state. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 common case. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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': forms.CharField(widget=forms.Textarea(), ...),
> > 'other_field': None,
> > }
>
> This syntax would not be completely DRY. If, for example, the model's
> 'text' field was optional (blank=True), you would need to explicitly
> specify the form field as optional (required=False) as well:
>
> ...
> 'text': forms.CharField(widget=forms.Textarea(),
> required=False...),
> ...
>
> By having a separate 'widgets' option you could modify the widgets
> independently from anything else. Not only is that DRY but also that
> would prevent some potential mistakes.
Also, you can already completely override a field like follows:
class MyForm(forms.ModelForm):
title = forms.CharField(widget=forms.Textarea(), ...)
class Meta:
model = Article
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 not be completely DRY. If, for example, the model's
'text' field was optional (blank=True), you would need to explicitly
specify the form field as optional (required=False) as well:
...
'text': forms.CharField(widget=forms.Textarea(),
required=False...),
...
By having a separate 'widgets' option you could modify the widgets
independently from anything else. Not only is that DRY but also that
would prevent some potential mistakes.
> On Sep 29, 11:07 am, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> > 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 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 another line and also shows that such things can easily be
> > > forgotten in real code.
>
> > > > Do we really need another way of doing this? Or am I overlooking
> > > > something that this new method introduces?
>
> > > I've addressed this exact thing my first email on subject, so quoting
> > > myself:
>
> > > > Here the problem is that it has enough boilerplate code to be, shall we
> > > > say, not beautiful. And also it defeats nice declarative nature of a
> > > > ModelForm.
>
> > > So, yes, it's not the end of the world but it's the same convenience as
> > > `fields` or `exclude` that all could be simulated in __init__.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 MyForm(forms.ModelForm):
class Meta:
fields = {
'text': forms.CharField(widget=forms.Textarea(), ...),
'other_field': None,
}
Where the 'None' indicates "do the default". This way you could
completely redefine the behaviour of the model form. Putting in a list
or tuple would just do what it's always done.
Regards,
Zack
On Sep 29, 11:07 am, SmileyChris <[EMAIL PROTECTED]> wrote:
> 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 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 another line and also shows that such things can easily be
> > forgotten in real code.
>
> > > Do we really need another way of doing this? Or am I overlooking
> > > something that this new method introduces?
>
> > I've addressed this exact thing my first email on subject, so quoting
> > myself:
>
> > > Here the problem is that it has enough boilerplate code to be, shall we
> > > say, not beautiful. And also it defeats nice declarative nature of a
> > > ModelForm.
>
> > So, yes, it's not the end of the world but it's the same convenience as
> > `fields` or `exclude` that all could be simulated in __init__.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 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 another line and also shows that such things can easily be > forgotten in real code. > > > Do we really need another way of doing this? Or am I overlooking > > something that this new method introduces? > > I've addressed this exact thing my first email on subject, so quoting > myself: > > > Here the problem is that it has enough boilerplate code to be, shall we > > say, not beautiful. And also it defeats nice declarative nature of a > > ModelForm. > > So, yes, it's not the end of the world but it's the same convenience as > `fields` or `exclude` that all could be simulated in __init__. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 another line and also shows that such things can easily be forgotten in real code. > Do we really need another way of doing this? Or am I overlooking > something that this new method introduces? I've addressed this exact thing my first email on subject, so quoting myself: > Here the problem is that it has enough boilerplate code to be, shall we > say, not beautiful. And also it defeats nice declarative nature of a > ModelForm. So, yes, it's not the end of the world but it's the same convenience as `fields` or `exclude` that all could be simulated in __init__. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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):
> >> class Meta:
> >> model = Article
> >> fields = ['author', 'text']
> >> widgets = {
> >> 'text': Textarea(...),
> >> }
>
> >> I know it can be done now with formfieldcallback but it doesn't look
> >> nearly as readable because you have to write an imperative logic
> >> comparing field names.
>
> > +1. I think this would wrap up one of the last reasons to use
> > formfield_callback, but I think it should be on the post-1.0 list.
>
> Hello everyone!
>
> I've just got to implementing this:http://code.djangoproject.com/ticket/9223
>
> The patch is rather simple, backwards-compatible, contains tests and
> docs. I suppose docs require some proof-reading, as usual.
I've always just done this by doing:
MyForm(ModelForm)
model = MyModel
def __init__(self, *args, **kwargs):
self.fields['name'].widget = Textarea() # or whatever
Do we really need another way of doing this? Or am I overlooking
something that this new method introduces?
Something else to consider is how this effects subclasses (I haven't
thought to much about it, just raising a potential gotcha)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in 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 = ['author', 'text']
>> widgets = {
>> 'text': Textarea(...),
>> }
>>
>> I know it can be done now with formfieldcallback but it doesn't look
>> nearly as readable because you have to write an imperative logic
>> comparing field names.
>
> +1. I think this would wrap up one of the last reasons to use
> formfield_callback, but I think it should be on the post-1.0 list.
Hello everyone!
I've just got to implementing this:
http://code.djangoproject.com/ticket/9223
The patch is rather simple, backwards-compatible, contains tests and
docs. I suppose docs require some proof-reading, as usual.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 following should already somewhat do what you
> want in most cases, although it's obviously not very nice:
>
> class ArticleForm(ModelForm):
> author =
> Article._meta.get_field('author').formfield(**custom_options)
> class Meta:
> model = Article
I do something like this right now. I even have a shortcut function
"model_field" for this which makes it shorter. However, see:
class ArticleForm(ModelForm):
author = model_field(Article, 'author', attrs)
class Meta:
model = Article
every such field definition forces me to repeat field's name twice and
also repeat a model that is already set in Meta.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
> 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, or the the choices option of a ModelChoiceField - I also have
to redefine the whole field. Why not do something like:
class ArticleForm(ModelForm):
text = {'widget': 'Text'}
author = {'label': Textarea(...)}
class Meta:
model = Article
fields = ['author', 'text']
Or, more explicit:
class ArticleForm(ModelForm):
text = Attrs(widget='Text')
By the way, IIRC the following should already somewhat do what you
want in most cases, although it's obviously not very nice:
class ArticleForm(ModelForm):
author =
Article._meta.get_field('author').formfield(**custom_options)
class Meta:
model = Article
Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 PROTECTED]> wrote: >> 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 installation. I'm merely asking *if* it's sane enough to >> be in Django itself. If yes I'm happy to make a patch. > > > -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 think that still belongs to the init method, not the Meta class. On Jul 6, 11:20 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > 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 installation. I'm merely asking *if* it's sane enough to > be in Django itself. If yes I'm happy to make a patch. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 your idea is good, and why I vote +1 for it: Adding more and more declarative options to ModelForm and for NFA's ModelAdmin is good, cause it's making simple forms easier to write. 90% of application forms are typical, let's make them declarative if it's possible. 100% of developers want to make their simple forms even more simple (some forms will always be custom). On Sun, Jul 6, 2008 at 8:20 PM, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > 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 installation. I'm merely asking *if* it's sane enough to > be in Django itself. If yes I'm happy to make a patch. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 installation. I'm merely asking *if* it's sane enough to be in Django itself. If yes I'm happy to make a patch. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 everywhere ;)
On Sun, Jul 6, 2008 at 6:27 PM, Ivan Sagalaev
<[EMAIL PROTECTED]> 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 edit in a form:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
>
> This is nice! But now I want to use a bit larger textarea for 'text' and
> want specify it with attrs={'cols': 80, 'rows': 20}. Currently I have
> two options:
>
> 1. Redeclare entire field:
>
> class ArticleForm(ModelForm):
> text = CharField(
> u'Text',
> is_required=True,
> widget=Textarea(...))
>
> class Meta:
> model = Article
> fields = ['author']
>
> The problem is that along with a widget I have to repeat other
> attributes of a field: type, label, required-ness, help_text etc...
> Which is bad because it's, ahem, "non DRY" :-). It's also looks a bit
> strange because now fields are declared in two different ways.
>
> 2. Fix widget in __init__:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
>
> def __init__(self, *args, **kwargs):
> super(ArticleForm, self).__init__(*args, **kwargs)
> self.fields['text'].widget = Textarea(...)
>
> Here the problem is that it has enough boilerplate code to be, shall we
> say, not beautiful. And also it defeats nice declarative nature of a
> ModelForm.
>
> In other words the problem of ModelForm is that we have very usefule
> separation between fields and widgets but we cannot declare them separately.
>
>
> ## Proposal
>
> To fix this I was thinking along the lines of:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
> widgets = {
> 'text': Textarea(...),
> }
>
> I know it can be done now with formfieldcallback but it doesn't look
> nearly as readable because you have to write an imperative logic
> comparing field names.
>
> Sound sane?
>
> >
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
> ## 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 sane?
The proposal sounds reasonable to me. I too find the current ways for
customizing ModelForm defeating the whole purpose of it (ie.
simplicity/cleanliness)...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 default select multiple. P.S. And if you allow me to be pedantic, cols and rows attributes are not presentational. They even required by HTML 4.01. So CSS here is not an adequate replacement. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
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 edit in a form:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
>
> This is nice! But now I want to use a bit larger textarea for 'text' and
> want specify it with attrs={'cols': 80, 'rows': 20}. Currently I have
> two options:
>
> 1. Redeclare entire field:
>
> class ArticleForm(ModelForm):
> text = CharField(
> u'Text',
> is_required=True,
> widget=Textarea(...))
>
> class Meta:
> model = Article
> fields = ['author']
>
> The problem is that along with a widget I have to repeat other
> attributes of a field: type, label, required-ness, help_text etc...
> Which is bad because it's, ahem, "non DRY" :-). It's also looks a bit
> strange because now fields are declared in two different ways.
>
> 2. Fix widget in __init__:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
>
> def __init__(self, *args, **kwargs):
> super(ArticleForm, self).__init__(*args, **kwargs)
> self.fields['text'].widget = Textarea(...)
>
> Here the problem is that it has enough boilerplate code to be, shall we
> say, not beautiful. And also it defeats nice declarative nature of a
> ModelForm.
>
> In other words the problem of ModelForm is that we have very usefule
> separation between fields and widgets but we cannot declare them separately.
>
>
> ## Proposal
>
> To fix this I was thinking along the lines of:
>
> class ArticleForm(ModelForm):
> class Meta:
> model = Article
> fields = ['author', 'text']
> widgets = {
> 'text': Textarea(...),
> }
>
> I know it can be done now with formfieldcallback but it doesn't look
> nearly as readable because you have to write an imperative logic
> comparing field names.
>
> Sound sane?
>
What's CSS for?
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
