Re: Discussion: ModelForms not allowing unbounded RangeField values

Hey James, Thanks for your follow-up here. I think for me the thing that's compelling is the flow you describe in comment 12 : * A user renders an unbound model form, where all model fields have defaults. * The form is pre-filled with

Discussion: ModelForms not allowing unbounded RangeField values

For others getting up to speed, prior discussion is here: https://code.djangoproject.com/ticket/29656. Tim's comment from the ticket commentary is most instructive, I think: > I'm not sure if there's a model field in Django where there's a chance for > two values that could be considered "em

Re: [GSoC] Dynamic, rule-based ModelForms

On Thursday 06 March 2014 01:17:51 Paolo Coffetti wrote: > Hi Django devs, > > I want to share an idea with you and get some feedback in order to know if > it makes sense, if it could solve a common problem and maybe evolve into an > official GSoC proposal. > > Some years ago I was working on a p

[GSoC] Dynamic, rule-based ModelForms

Hi Django devs, I want to share an idea with you and get some feedback in order to know if it makes sense, if it could solve a common problem and maybe evolve into an official GSoC proposal. Some years ago I was working on a printing on demand website using Django 1.2 and some model forms. Our

Re: ModelForms and the Rails input handling vulnerability

On 12 helmi, 14:10, Emil Stenström wrote: > On Monday, 4 February 2013 15:06:18 UTC+1, Aymeric Augustin wrote: > > > Hi Luke, > > > This sounds like a good compromise between security and usability. > > I just want to add another voice of support for Option 3 to this thread. > > I'm one of the dev

Re: ModelForms and the Rails input handling vulnerability

On Monday, 4 February 2013 15:06:18 UTC+1, Aymeric Augustin wrote: > > Hi Luke, > > This sounds like a good compromise between security and usability. > I just want to add another voice of support for Option 3 to this thread. I'm one of the developers for a large site, with ~40 apps, that has g

Re: ModelForms and the Rails input handling vulnerability

Le 4 févr. 2013 à 14:35, Luke Plant a écrit : > I like Alex Ogier's solution of a sentinel "__all__" flag. This would be > introduced for ModelForm and UpdateView using a deprecation process, so > that a form without one of 'fields' or 'exclude' will raise a > PendingDeprecation warning initially

Re: ModelForms and the Rails input handling vulnerability

This is an old thread, but we never came to a conclusion. I'll respond to Anssi below, and then add my own ideas. > I find the option of raising warnings or errors on missing data > elements the best option forward. There is one unfortunate downside, > that is we can't do this for checkboxes. So,

Re: ModelForms and the Rails input handling vulnerability

On 14 kesä, 08:53, Torsten Bronger wrote: > Hall chen! > > Alex Ogier writes: > > [...] > > > That suggests an idea to me. Perhaps the best way to check this > > isn't on the way out in the template renderer, but rather on the > > way back in in the form validation. If the form doesn't get back >

Re: ModelForms and the Rails input handling vulnerability

> On Tue, Jun 19, 2012 at 8:42 PM, Honza Král wrote: >> I believe exclude is way more useful than fields (I do see the >> security advantage but in my mind this is the case where convenience >> beats security, also still afraid of the fields = [f.name for f in >> ...]). > > Personally, I don't thi

Re: ModelForms and the Rails input handling vulnerability

Hi, I'm with Carl in supporting option 3. I think have always thought that ModelForms were unsafe and requiring the fields option would go a long way to making them safer. I don't think I'm stupid and I've personally run into this issue. I have almost *NEVER* run into a c

Re: ModelForms and the Rails input handling vulnerability

Thanks Luke for writing this up and representing all views. I am the proponent of "we are all adults here". On Thu, Jun 14, 2012 at 6:48 AM, Anssi Kääriäinen wrote: > ... > I hadn't realized all fields present on the Python form but not in the > HTML form will get overwritten to NULL... The above

Re: ModelForms and the Rails input handling vulnerability

On 17 kesä, 23:14, Erik Romijn wrote: > Especially after seeing Jessica McKellar's keynote at Djangocon EU, on > the experience of novice developers when using Django, I strongly feel > we should not leave the situation as it is. Although this risk and it's > mitigations may be obvious to people o

Re: ModelForms and the Rails input handling vulnerability

is little to no extra effort in option 3 compared to option 2 - as those forms would require the same work when Meta.exclude is dropped. If the effort for both options is equal (for the developers), then I figure option 3 would be best. Looking at my own projects, all editing of data in ModelForms is

Re: ModelForms and the Rails input handling vulnerability

rences in browsers. The branch is available here: https://github.com/akaariai/django/compare/warn_missing_keys I don't see our ModelForms situation as comparable to the Rails situation. The scope for security issues is much smaller for us than for Rails. - Anssi -- You received this message becau

Re: ModelForms and the Rails input handling vulnerability

On Jun 14, 2012 1:54 AM, "Torsten Bronger" wrote: > > But can one guarantee that fields rendered in the browser are also > sent back in the POST request? Even worse, how about non-browser > requests? > Ugh. I forget that checkboxes don't return anything else when they are unchecked. Kind of thro

Re: ModelForms and the Rails input handling vulnerability

On Jun 14, 2012 12:48 AM, "Anssi Kääriäinen" wrote: > > This seems to be different from what Rails do: they have > update_attributes which updates all model attributes present in the > request, but lefts all others untouched. So, in Rails if you render > only part of the fields in update view, the

Re: ModelForms and the Rails input handling vulnerability

Hallöchen! Alex Ogier writes: > [...] > > That suggests an idea to me. Perhaps the best way to check this > isn't on the way out in the template renderer, but rather on the > way back in in the form validation. If the form doesn't get back > exactly those fields it sent out then you know that for

Re: ModelForms and the Rails input handling vulnerability

On 14 kesä, 03:12, Doug Blank wrote: > I, too, was thinking about this kind of solution. In fact, it came up > for me the other day because I had forgotten to exclude a field that I > did not have on the form, and so the value ended up getting wiped out > when I saved. So, perhaps a solution that

Re: ModelForms and the Rails input handling vulnerability

10:18, Carl Meyer wrote: > On 06/13/2012 06:12 PM, Doug Blank wrote: > > On Wed, Jun 13, 2012 at 5:05 PM, Carl Meyer wrote: > >> On 06/13/2012 02:55 PM, Peter wrote: > >>> Can I throw in option 5: > >>> > >>> We leave ModelForms as they are,

Re: ModelForms and the Rails input handling vulnerability

On Jun 13, 2012 8:12 PM, "Doug Blank" wrote: > > I, too, was thinking about this kind of solution. In fact, it came up > for me the other day because I had forgotten to exclude a field that I > did not have on the form, and so the value ended up getting wiped out > when I saved. So, perhaps a solu

Re: ModelForms and the Rails input handling vulnerability

On 06/13/2012 06:12 PM, Doug Blank wrote: > On Wed, Jun 13, 2012 at 5:05 PM, Carl Meyer wrote: >> On 06/13/2012 02:55 PM, Peter wrote: >>> Can I throw in option 5: >>> >>> We leave ModelForms as they are, but emit a warning if you only >>> partia

Re: ModelForms and the Rails input handling vulnerability

On Wed, Jun 13, 2012 at 5:05 PM, Carl Meyer wrote: > Hi Peter, > > On 06/13/2012 02:55 PM, Peter wrote: >> Can I throw in option 5: >> >> We leave ModelForms as they are, but emit a warning if you only >> partially render the form? >> >> I'm not

Re: ModelForms and the Rails input handling vulnerability

Hi Peter, On 06/13/2012 02:55 PM, Peter wrote: > Can I throw in option 5: > > We leave ModelForms as they are, but emit a warning if you only > partially render the form? > > I'm not sure how feasible this is, but presumably we could keep track of > which fields have

Re: ModelForms and the Rails input handling vulnerability

Hi all, Can I throw in option 5: We leave ModelForms as they are, but emit a warning if you only partially render the form? I'm not sure how feasible this is, but presumably we could keep track of which fields have been rendered for a given form instance? That way, if you render the

Re: ModelForms and the Rails input handling vulnerability

On 06/13/2012 12:57 PM, Anssi Kääriäinen wrote: > The point is the same form with the same fields can be used in > multiple places. There is no need for dynamic addition and removal of > fields in Python code. The dynamism is in which fields to display - > not which fields the form contains. You re

Re: ModelForms and the Rails input handling vulnerability

Hi list, as I use "exclude" most of the times (to hide sensible fields from the user) I don't like the idea of this beeing removed. Perhaps another solution might be to force developers to either define fields _or_ exclude, so you have to at least think about this..without going through too much t

Re: ModelForms and the Rails input handling vulnerability

o think that if you don't have the fields in the HTML form, then the user can't edit the fields. It would be useful to know how many projects contain ModelForms with no field restrictions, and only display a subset and always the same subset of the fields. - Anssi -- You received this

Re: ModelForms and the Rails input handling vulnerability

list all the model fields that should be editable. Without it, > ModelForms would not work at all. > > This also means deprecating Meta.exclude (it's redundant once you are > saying that all fields should be explicitly whitelisted). > What about a fourth option: = Option 4: M

Re: ModelForms and the Rails input handling vulnerability

e). > "Explicit is better than implicit". > > The option doesn't make an assumption that models are either 'sensitive' > or not. It is also more consistent than option 2: if you add a field to > a model, you know that if it is meant to be publicly editable,

Re: ModelForms and the Rails input handling vulnerability

gt;> >> The policy here is essentially this: if any fields the model are >> sensitive, assume all are potentially, and require whitelisting, not >> blacklisting. >> >> = Option 3: Make the 'Meta.fields' attribute a required attribute, which >> must lis

Re: ModelForms and the Rails input handling vulnerability

kolowski < daniel.sokolow...@klinsight.com> wrote: > (I apologize if this is a duplicate - my other account appears to have an > issue sending to this group) > > I'm in the camp don't change it. ModelForms are doing what they are > designed to do: providing a very ha

Re: ModelForms and the Rails input handling vulnerability

(I apologize if this is a duplicate - my other account appears to have an issue sending to this group) I'm in the camp don't change it. ModelForms are doing what they are designed to do: providing a very handy short cut. It is a design decision to either use a ModelForm, or a a

Re: ModelForms and the Rails input handling vulnerability

hat we would have huge name list in 80% of the ModelForms. Moreover, they needed to be kept up-to-date, which is very error-prone. Granted that it's worse if security is affected, but legibility and DRY would be reduced too drastically in my opinion by option 2. People in a similar situation

Re: ModelForms and the Rails input handling vulnerability

potentially, and require whitelisting, not > blacklisting. > > = Option 3: Make the 'Meta.fields' attribute a required attribute, which > must list all the model fields that should be editable. Without it, > ModelForms would not work at all. I support option 2. I will try

Re: ModelForms and the Rails input handling vulnerability

On Tue, Jun 12, 2012 at 11:43 PM, Karen Tracey wrote: > On Tue, Jun 12, 2012 at 10:10 PM, Alex Ogier wrote: >> >> No one can sneak extra unexpected fields past a developer by editing HTML >> client side, because if the field wasn't rendered to HTML it's not >> going to validate. > > > But it may.

Re: ModelForms and the Rails input handling vulnerability

On 13 June 2012 09:16, Luke Plant wrote: > = Option 2: Deprecate Meta.exclude, but still allow a missing > Meta.fields attribute to indicate that all fields should be editable. > > The policy here is essentially this: if any fields the model are > sensitive, assume all are potentially, and requir

Re: ModelForms and the Rails input handling vulnerability

On Tue, Jun 12, 2012 at 10:10 PM, Alex Ogier wrote: > No one can sneak extra unexpected fields past a developer by editing HTML > client side, because if the field wasn't rendered to HTML it's not > going to validate. > But it may. If you have a template which renders specific fields, and yet th

Re: ModelForms and the Rails input handling vulnerability

rabilities in Rails apps. > > For us, we don't have this issue because we have the forms layer that > sits between the HTTP request and model creation, and that's the > recommended way to do things. > > However, in the case of ModelForms, you can easily get to a situati

ModelForms and the Rails input handling vulnerability

's the recommended way to do things. However, in the case of ModelForms, you can easily get to a situation where you've effectively got the same thing as Rails. In theory you've got the forms layer, but in reality your form was autogenerated using all the fields on the model. This happens

Re: ModelForms regression since Django 1.1.2

een overlooked: > http://code.djangoproject.com/ticket/13679 > > There was a regression in Django 1.1.2 that's causing ModelForms to > ignore callable defaults for ForeignKeys. I attached a simple test > case to the ticket today that will hopefully make it easy to see the > pr

ModelForms regression since Django 1.1.2

Hi everyone, I'm writing to draw attention to a ticket I opened a couple of months ago that seems to have been overlooked: http://code.djangoproject.com/ticket/13679 There was a regression in Django 1.1.2 that's causing ModelForms to ignore callable defaults for ForeignKeys. I attache

Re: ModelForms and ForeignKeys causing ValueError

Submitted here: http://code.djangoproject.com/ticket/13776 On Jun 14, 2:05 pm, Karen Tracey wrote: > On Mon, Jun 14, 2010 at 12:39 PM, Peter Bengtsson wrote: > > I'm happy to submit a ticket but wanted to check first that I'm doing > > the right thing. I think this used to work in Django 1.1 but

Re: ModelForms and ForeignKeys causing ValueError

On Mon, Jun 14, 2010 at 12:39 PM, Peter Bengtsson wrote: > I'm happy to submit a ticket but wanted to check first that I'm doing > the right thing. I think this used to work in Django 1.1 but not now > in trunk. > > I can better explain it with code: > > [snip details] > The point of this is that

ModelForms and ForeignKeys causing ValueError

I'm happy to submit a ticket but wanted to check first that I'm doing the right thing. I think this used to work in Django 1.1 but not now in trunk. I can better explain it with code: # models.py class FooBarModel(models.Model): name = models.CharField(max_length=10) age = models.IntegerF

Re: Model validation outside of ModelForms.

Thanks James, I'll focus on this here and see what I can come up with. 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-develop...@googlegroups.com. To unsubscribe from this group, send

Re: Model validation outside of ModelForms.

On Thu, Jan 21, 2010 at 1:28 PM, Gerry wrote: > without using ModelForms? I really like the new Model validation but I > don't > like (nor think its very DRY) to override the save method for all of > my models > to just call full_clean(). It would be nice if there was some

Re: Model validation outside of ModelForms.

On Wed, Mar 17, 2010 at 1:00 AM, orokusaki wrote: > Actually I'm not lying. Russell hasn't given me any feedback regarding > my idea or patch. I didn't simply reopen tickets. Russell changed my > ticket to a documentation ticket, so I opened a new ticket to discuss > that which he avoided in his d

Re: Model validation outside of ModelForms.

On Mar 16, 10:16 am, Harro wrote: > Just my brainfart when looking at this: Can't you simply add a pre > save signal to call the full clean method? > > Dunno if that will work or not, just the first thing I would try. > > On Mar 16, 5:12 pm, James Bennett wrote: > Hey James, I've not used sign

Re: Model validation outside of ModelForms.

On Mar 16, 10:12 am, James Bennett wrote: > On Tue, Mar 16, 2010 at 10:36 AM, orokusaki wrote: > > It doesn't seem that the core team is interested in working on Model > > validation at the moment:http://code.djangoproject.com/ticket/13121 > > (my failed ticket) > > Stop right there and actuall

Re: Model validation outside of ModelForms.

Just my brainfart when looking at this: Can't you simply add a pre save signal to call the full clean method? Dunno if that will work or not, just the first thing I would try. On Mar 16, 5:12 pm, James Bennett wrote: > On Tue, Mar 16, 2010 at 10:36 AM, orokusaki wrote: > > It doesn't seem that

Re: Model validation outside of ModelForms.

On Tue, Mar 16, 2010 at 10:36 AM, orokusaki wrote: > It doesn't seem that the core team is interested in working on Model > validation at the moment: http://code.djangoproject.com/ticket/13121 > (my failed ticket) Stop right there and actually go back and *read* all the feedback you've gotten, be

Re: Model validation outside of ModelForms.

g the API for existing users. This is simply not true. With ValidationError propagating upwards from the model level, ModelForm would need nothing to do with validation besides displaying the errors to the user. This is the common sense approach to ModelForms anyway, and the only people who would s

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

> > Thanks, the accompanying discussion is very interesting and on point. > > But as someone there points out, why stop at widgets? > > Because customizing widgets is a common request, unlike other attributes. But customizing fields is quite common, no? I agree that it's rare that you will want t

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

Kevin Henry wrote: >> There's also a ticket waiting for check-in implementing this common >> usecase:http://code.djangoproject.com/ticket/9223 > > Thanks, the accompanying discussion is very interesting and on point. > But as someone there points out, why stop at widgets? Because customizing wid

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

> Please file a ticket for the documentation fix it would be greatly   > appreciated. :-) Will do. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to djan

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

In terms of backward compatibility, perhaps there could be a new keyword argument to Field, something like with_model_defaults, that the user would use to indicate a desire to get the attributes from the Model. How would this work? Maybe something like this (this is just a sketch): Field.__init__(

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

Malcolm Tredinnick wrote: > If all you want to do is change the widget, you can do that in the > form's __init__ method by updating self.fields["name"].widget, for > example. There's also a ticket waiting for check-in implementing this common usecase: http://code.djangoproject.com/ticket/9223 P

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

If you want inherit default attributes from model just use name = Author._meta.get_field('name').formfield() --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, sen

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

On Aug 13, 2009, at 1:59 PM, Kevin Henry wrote: > >> Well, surprise is in the eye of the participant. As noted above, it >> would be surprising to a lot of us if it did pick up the attributes >> because it removes control from the user. The current behaviour isn't >> illogical. > > Oh, I wasn't

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

> Well, surprise is in the eye of the participant. As noted above, it > would be surprising to a lot of us if it did pick up the attributes > because it removes control from the user. The current behaviour isn't > illogical. Oh, I wasn't suggesting that the user shouldn't be able to override thos

Re: Shouldn't custom fields in ModelForms pick up model Field options by default?

it would be surprising to a lot of us if it did pick up the attributes because it removes control from the user. The current behaviour isn't illogical. > and should probably be documented here: > http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#overriding-the-default-field-

Shouldn't custom fields in ModelForms pick up model Field options by default?

e model field options (that is, there is no help text, no default value, and you can't save it blank). This seems like undesirable behavior. At the very least it's surprising, and should probably be documented here: http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#overriding-

Re: Shared declarative syntax in both ModelAdmin and ModelForms.

On Jul 6, 2008, at 4:36 PM, Yuri Baburov wrote: > At least they have or might have in common: > * editable fields > * readonly fields > * fields display order > * associated model > * inline subforms > * dynamic choices > * widgets > * widget resources: css/js files > * validators and validation

Re: Shared declarative syntax in both ModelAdmin and ModelForms.

eclarative syntax for ModelAdmin as Ivan >> suggested for ModelForms below. >> >> ModelAdmin and ModelForms both are quite similar already in NFA, and I >> think it would be The Right Thing if 90% of their features to be the >> same and they will have only one implementatio

Re: Shared declarative syntax in both ModelAdmin and ModelForms.

On Sun, Jul 6, 2008 at 9:01 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote: > > Hi all, > > I'd like to propose the same declarative syntax for ModelAdmin as Ivan > suggested for ModelForms below. > > ModelAdmin and ModelForms both are quite similar already in NFA, and

Shared declarative syntax in both ModelAdmin and ModelForms.

Hi all, I'd like to propose the same declarative syntax for ModelAdmin as Ivan suggested for ModelForms below. ModelAdmin and ModelForms both are quite similar already in NFA, and I think it would be The Right Thing if 90% of their features to be the same and they will have onl

Re: Initial values for ModelForms with additional fields

On Fri, 2008-04-18 at 11:47 -0400, Jay Wineinger wrote: > I realize that you can do it with initial. I was asking (unclearly, > evidently) if there would be any value to changing django to work in > that way. One way to do any given thing is enough. Your method isn't really anysaving in typin

Re: Initial values for ModelForms with additional fields

I realize that you can do it with initial. I was asking (unclearly, evidently) if there would be any value to changing django to work in that way. Jay [EMAIL PROTECTED] wrote: > This question should be directed to django-users, this group is for > django development, not support. > > > > cla

Initial values for ModelForms with additional fields

I posed this question on IRC and was told to direct it here because it might be "interesting". I created a ModelForm with additional fields which aren't present on the model. Now, I want to use this form to edit an instance of the model, but there doesn't seem to be a way set the additional fiel

Re: Initial values for ModelForms with additional fields

This question should be directed to django-users, this group is for django development, not support. class MyModel(models.Model): field_a = field_b = class MyModelForm(forms.ModelForm): field_c = ... class Meta: model = MyModel mymodel = MyModel() mymodel.fi

Re: validators as Meta attribute in ModelForms

Honza Král wrote on 04/16/08 00:13: > Hi, > check out ticket #6845 ( http://code.djangoproject.com/ticket/6845 ). > It enables you to define validators on both DB Fields and FormFields > and should make your work much easier. > Hi Honza Found your ticket just after posting this :) Will keep an

Re: validators as Meta attribute in ModelForms

Hi, check out ticket #6845 ( http://code.djangoproject.com/ticket/6845 ). It enables you to define validators on both DB Fields and FormFields and should make your work much easier. On Sun, Apr 13, 2008 at 6:09 PM, Steven Armstrong <[EMAIL PROTECTED]> wrote: > > Hi > > I've made a small change t

validators as Meta attribute in ModelForms

Hi I've made a small change to the ModelForm framework to allow declarative definition of validators. This allows for quick and easy reuse of validators and means I have to write less clean_foo methods. This works both in the admin as in custom views. What used to be written like this: clas

Re: About ModelForms implicitness and ways to wrap ModelForms

On Wed, 2008-04-02 at 17:06 -0700, msaelices wrote: > This mail maybe can be splitted in two, but I write only one because > both are related. > > Ok, ModelForms is a very very wonderful thing, but I want to talk > about (maybe) excessive implicitness. > > Look at

Re: About ModelForms implicitness and ways to wrap ModelForms

On 4 abr, 00:28, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > What about replacing the idea of a ModelForm with a ModelField? Then > for shorter > forms you could list all the fields explicitly, without having to > recode all the > default field definitions. I think should be hard to implemen

Re: About ModelForms implicitness and ways to wrap ModelForms

fields, and the real action is a _redefinition_ > >  of two fields. > > >  Django philosophy talk about "Explicit better than implicit", but in > >  this point ModelForms is not very intuitive. > > Obligatory counterpoint: it's not "intuitive", but t

Re: About ModelForms implicitness and ways to wrap ModelForms

tion_ > of two fields. > > Django philosophy talk about "Explicit better than implicit", but in > this point ModelForms is not very intuitive. Obligatory counterpoint: it's not "intuitive", but that's an awfully loaded word, since no two programmers ever born

About ModelForms implicitness and ways to wrap ModelForms

This mail maybe can be splitted in two, but I write only one because both are related. Ok, ModelForms is a very very wonderful thing, but I want to talk about (maybe) excessive implicitness. Look at this form declaration: class AuthorForm(forms.Form): name = myforms.MyCharField(max_length

Re: ModelForms paranoia simplification?

On Thu, 2008-02-14 at 08:49 -0800, aconbere wrote: [...] > +1 I'm all for changes that make things consistent with the behavior > of python. Well, let's not overrate the importance of this. That particular code would only have been visible if you did something dumb. It wasn't going to mislead pe

Re: ModelForms paranoia simplification?

On Feb 13, 11:14 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > There's a bunch of code in ModelForms.__new__ that tries to protect > people from themselves for what looks like a real edge case. > > In normal Python code, if you have a class that subclasses from mul

Re: ModelForms paranoia simplification?

On Thu, Feb 14, 2008 at 1:14 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Any strong objections to not behaving like Python here? No. Please make the change. I was looking at this the other day and had one of those "did I really write this?" moments. Thank you for taking care of #6337 [

Re: ModelForms paranoia simplification?

On Thu, Feb 14, 2008 at 1:14 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Any strong objections to not behaving like Python here? Sounds like it's well worth removing. +1. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~

Re: ModelForms paranoia simplification?

On Thu, Feb 14, 2008 at 8:14 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Any strong objections to not behaving like Python here? The less magic the better. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ You received this message because

Re: ModelForms paranoia simplification?

On Thu, 2008-02-14 at 18:14 +1100, Malcolm Tredinnick wrote: [...] > Any strong objections to not behaving like Python here? Oh, bother. Darn double-negatives. Remove the 'not'. Sentence makes more sense, then. Malcolm -- Honk if you love peace and quiet. http://www.pointy-stick.com/blog/

ModelForms paranoia simplification?

There's a bunch of code in ModelForms.__new__ that tries to protect people from themselves for what looks like a real edge case. In normal Python code, if you have a class that subclasses from multiple parents and you try to access an attribute on a parent, Python just picks the first occur

ModelForms w/no pre-set model

In a previous thread [1], there was talk of allowing ModelForm to work without a model hard-coded, so it would base it off the instance passed to the form. However, on trying to make that work, it seems that something may have been left out of the previous patch - if I don't include a model, i

Re: ModelForms

On 11/13/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On Nov 13, 2007 5:37 AM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > > On 11/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > > > The problem I have with ModelForm is that it doesn't feel like it has > > > any para

Re: ModelForms

On Nov 13, 2007 5:37 AM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > On 11/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > The problem I have with ModelForm is that it doesn't feel like it has > > any parallels with the existing class-based formdefinitions. ... > I see your poin

Re: ModelForms

On Nov 12, 2007 4:05 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > class Article(models.Model): > title = models.CharField(max_length=100) > body = models.TextField > > class ArticleForm(models.Model) > body = MyCustomBodyField() # override the default formfiel

Re: ModelForms

On 11/12/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > > On Nov 12, 2007 3:37 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > class MyForm(ModelForm): > > extra_field = SomeField() > > > > class Options: > > model = MyModel > > fields = ['list', 'of

Re: ModelForms

On Nov 12, 2007 3:37 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > class MyForm(ModelForm): > extra_field = SomeField() > > class Options: > model = MyModel > fields = ['list', 'of', 'field', 'names'] > > def formfield_callback(db_field)

Re: ModelForms

On 11/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > The problem I have with ModelForm is that it doesn't feel like it has > any parallels with the existing class-based formdefinitions. Manual > Form definitions have a very similar flavour to Model definitions - > each class attribute i

Re: ModelForms

On 11/10/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > On 11/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > I'd hate to see the obj arg get put into the constructor of a > BaseForm, so Form's metaclass would end up generating a subclass of > BaseForm or BaseModelForm depending o

Re: ModelForms

f my approach over yours is the > ability to display information about the author in the template, > alongside the other forms, but if that's really necessary, the author > can be passed separately in the context. I hadn't considered just > creating a new object preloaded wi

Re: ModelForms

On Nov 9, 2007 12:42 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > Why not just do this? No need for any special new fields at all. > > class Article(models.Model): > author = models.ForeignKey(User) > title = models.CharField(max_length=255) > body = models.TextFi

Re: ModelForms

On 11/9/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > > On Nov 9, 2007 9:57 AM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > The only thing it doesn't handle yet is how to remove > > fields from the customized form, but this might be as simple as > > assigning the field to None or some new Excluded

Re: ModelForms

On 11/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > If we're kicking around ideas on this, here's a slightly different > suggestion. First, an example: > > class MyForm(Form): > extra_field = forms.CharField() > > class Meta: > model = MyModel > fields = ('a','b'

Re: ModelForms

I'm agree with you, but this example is just for demonstration purposes, but concerning the proposition, we really need something to reuse our model definitions into forms without rewrite(DRY), since that a form field, in many cases, has the same validation rules in both, back end and front end.

Re: ModelForms

On Nov 9, 2007 10:07 AM, Smel <[EMAIL PROTECTED]> wrote: > PS : > http://smelaatifi.blogspot.com/2007/08/declarative-forms-django-newforms.html I'd say I'm -1 on including admin-style field declarations to forms. I'm of the mind that, if you need that level of design on a custom form, just write

  1   2   >