#14802: feature request: add a method to Fields that is used to render the
field as
read-only
---------------------------------------------+------------------------------
Reporter: nickname123 | Owner: cogat
Status: new | Milestone:
Component: django.contrib.admin | Version: 1.2
Resolution: | Keywords: sprintdec2010
hidden_widget
Stage: Design decision needed | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------
Comment (by nickname123):
Replying to [comment:3 cogat]:
> Just to clarify, a widget in Django is its representation of an HTML
input element, so it doesn't make sense to use it for anything that
doesn't involve displaying and handling an input element. So for read-only
fields there's no need to use a widget.
>
> Given this, I think you're asking for each Field to have a method that
is called by admin that renders the field as a read-only HTML. That's
something I could get behind (it's better to attach field display to
fields than to models, and there are currently silly special-cases for
rendering BooleanFields as icons in the current code) but it needs a
design decision. Particularly, would the same method, or a variation on
it, be used to render the field in admin list views? What about mechanisms
for requiring external javascript/css files needed by the rendering? What
about specifying read-only fields (so the same method can be used) in non-
admin forms?
>
> However, without a patch this won't make it into 1.3, so I'll remove the
milestone.
[[BR]]
In regards to your comment about widgets being the wrong term... the html
input tag does have a readonly attribute
(http://www.w3schools.com/tags/att_input_readonly.asp). I was talking
about using this since widgets are the current way of displaying form
fields that are not readonly. This seemed to be the "correct" way to do
it.
However, I did not put much thought into how it would be best achieved
because I was not sure if the feature had been left out of Django on
purpose.
A "to html" method might be a better idea, but I am still in favor using a
widget. I think a widget gives a little more abstraction and fits better
with the current design. Using a widget opposed to a method on the model
would have the benefit of being easily overridden too. I think it is a
nifty feature to be able to override the default widgets on the model
forms used by the admin interface and there is no reason not to allow the
same level of tweaking with readonly fields.
(http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.formfield_overrides
and http://docs.djangoproject.com/en/dev/topics/forms/modelforms
/#overriding-the-default-field-types-or-widgets)
--
Ticket URL: <http://code.djangoproject.com/ticket/14802#comment:7>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
