I've often longed for a "read-only" concept in ModelForms. For example, if I want the "site" field to always have a certain value (i.e. the current site) but also want to enforce multiple-column uniqueness (i.e. slug/site). I can write it myself, but it always feels like I shouldn't have to. Probably since the admin already provides that functionality.
Point being, that's something that, if it is implemented, should probably be implemented separately from the pk stuff which is currently being discussed. Personally, I haven't had much use for natural primary keys since I started using Django. (Though probably that's because it's so easy in django to use the AutoField pk and because so many things expect integer pks.) Are there a lot of people who use them? --Stephen On Dec 3, 7:58 pm, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > On Dec 3, 7:18 pm, Carl Meyer <c...@oddbird.net> wrote: > > > > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > On 12/03/2011 02:13 AM, Anssi K ri inen wrote: > > > > Admin should be fixed [#2259]. Making PK fields non-editable in > > > ModelForms would be good, too. Is it OK to consider the current > > > ModelForm behavior a bug, or will it need a deprecation cycle? > > > I think it would need a deprecation cycle. People certainly could be > > making use of the current behavior (and there would need to be a way to > > get the PK field back into the form, e.g. by explicitly listing it in > > "fields"). Excluding PK from ModelForm by default isn't clearly fixing a > > bug, it's more protecting people from unintuitive behavior. > > > (Note that in admin we have the option to display it read-only by > > default; ModelForm has no such feature, we'd have to exclude it entirely > > by default). > > This turns out to be a show-stopper. I think that in admin we could > just make the field non-editable when editing an object, but editable > when saving a new object. Save-as-new would be a problem, but probably > some workaround could be found. > > But for ModelForms, what to do? You would want to have the same > behavior as in admin: editable when adding, but non-editable when > editing an existing object. But the problem is, we do not have the > ability to show the value as non-editable. Could this be implemented > by a html attribute editable="false"? Ugly, but should work for most > cases. > > I do agree this needs a deprecation cycle. > > > > It is OK that Django doesn't support primary key updates. But if it > > > doesn't support update of PK, then lets error out on primary key > > > change. Current behavior of .save() is actually: "save the object to > > > DB, except when PK has changed, then do a clone". That is a bad API > > > for natural primary keys. > > > > About breaking current code: my intention is to have a flag to .save() > > > which would allow current code to work. .save(clone=True) would get > > > current behavior back. Setting the PK to None and doing a save will > > > work for AutoField PKs. > > > So what about admin users who are currently relying on this behavior as > > a way to clone objects with natural PKs (given that the > > save-and-add-another button is useless with natural PKs unless you can > > explicitly give the value for the new row)? > > Javascript magic? save-as-new disabled for natural PKs, instead you > get a "copy" button which opens another window? In other words, good > ideas welcome... > > - Anssi -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
