On Dec 5, 11:43 am, Stephen Burrows <stephen.r.burr...@gmail.com> wrote: > 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.
Me too. The good news is that it should be relatively easy to implement this after template based form rendering is implemented. You get the read-only widgets nearly for free. There is some added logic in the forms itself to handle the case of "do not handle data for this field", although that might boil down to "if field.read_only: continue" in a couple of places. The bad news is that template based rendering is blocked on faster template system. A test I did some time ago showed nearly 10x slower rendering in the worst case using template rendering compared to current "render in Python" implementation. The funny thing was that Jinja2 was actually _faster_ than current implementation, although that might be because of different escaping and localization. > Point being, that's something that, if it is implemented, should > probably be implemented separately from the pk stuff which is > currently being discussed. Agreed. > 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? There currently aren't that many users, and that is why the current behaviour of save cloning the object isn't a big problem. This will change if natural primary keys are included in Django. By definition they are part of the data model, and in most cases subject to change. Even if they are not subject to change, Django doesn't make it easy to enforce that (no support for read-only form fields, and save doesn't guard against accidental changes). So, my opinion is: - It is a good idea to block accidental PK changes in .save(). I think I have a working solution in #17332 - It is not a good idea to do this before read-only form fields are introduced. - It is a good idea to have as little state as possible for model instances. If first item is implemented, it unfortunately requires tracking of PK state. - It is a good idea to allow custom subclasses to track more state if they wish to do so. The patch in 17332 should make this easier to do (a little change needed, though: self._state = self._state_class() instead of self._state = ModelState()). In conclusion: I think the best thing to do is visit this subject again during 1.5 development cycle. - 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.
