Opened 16 years ago
Closed 16 years ago
#9376 closed (wontfix)
Support initial values for clean() not just for FileField
Reported by: | aszlig | Owned by: | nobody |
---|---|---|---|
Component: | Forms | Version: | dev |
Severity: | Keywords: | form fields | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
hi,
i appended a patch that adds a sneaky_initial attribute for custom form fields
(and for FileField, too) so that it is possible to write form fields/model
fields that contain values that could only be changed by submitting a new value
but to change them ad-hoc.
a! :-)
PS: a better name for the attr except "sneaky_initial" would be great :-D
Attachments (1)
Change History (5)
by , 16 years ago
Attachment: | sneaky_initial.diff added |
---|
comment:1 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 16 years ago
hullo,
maybe we are talking about different things, i'll try to explain it with
my specific problem:
i'm trying to implement a custom model field called KeyField, which
should contain a SSH public/private key that's serialized into the
database. the goal is now that the user can supply new keys (in a
textarea) but another user shouldn't be able to see the contents of the
key but in turn should be able to overwrite the value with a new key.
so the usage would be almost the same as with a FileField except the
the fact that keys aren't uploaded as files and not written as files
into the media root.
if i wipe out the self.initial this won't help much, or am i confused
now? O_o
thanks btw for the fast response =)
a!
comment:3 by , 16 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
comment:4 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
This is the sort of specialised use-case that is best done in the custom form field's initialisation and/or cleaning methods. You have complete control over what is displayed and stored in the field class. Just subclass __init__
appropriately; this doesn't need any modifications on the Field class.
FileFields are a special case where the HTML widget doesn't render any initial value, so we have to handle them specially. All other HTML form fields render initial values without problems, so they're different at that level.
This seems like an edge case and it's easy enough to implement it in a custom form field (just override
__init__
and wipe out the value ofself.initial
), so I don't think it's worth adding to Django's core.Thanks for the patch anyway (in future, though, a patch like this would also need tests and documentation to explain it).