When I want to just display data in a form (as opposed to letting user
edit it), I create a specialized widget. For example, I have a model
that has multiple datetime fields, and I don't want the user to be
able to edit them, but I do want to display their values. Here's a
widget I use where you pass it some when you intiailize it (the task
it's operating on and the field name to display). Its render() method
just renders the specified field:
class TaskForm_DisplayDateTimeWidget(widgets.Widget):
def __init__(self, task=None, fieldNameToDisplay=None, attrs =
{}):
self.task = task
self.fieldNameToDisplay=fieldNameToDisplay
super(TaskForm_DisplayDateTimeWidget, self).__init__(attrs)
def render(self, name, value, attrs=None):
rendered = ""
if self.task and self.fieldNameToDisplay:
dateVal = getattr(self.task, self.fieldNameToDisplay)
if dateVal:
rendered = mark_safe("%s" % date(dateVal, "%s %s" %
(settings.DATE_FORMAT, settings.TIME_FORMAT)))
return rendered
In my form, which is a model form, I declare the field like this in
"class global" area (l the area that is in the class but not in any
method:
displayModified = DisplayField(label="modified", widget =
DisplayDateTimeWidget, required=False)
Then in __init__() I do this:
instance = kwargs.get("instance")
if instance:
self.fields["displayModified"].widget =
DisplayDateTimeWidget(task=instance, fieldName="displayModified")
My form is a modelForm, so I do not put this field in Meta.fields, as
that would cause django to do some extra stuff like atempt to clean
the field, which doesn't make any sense since there is no input. So
basically I'm using all the form and widget infrastructure that django
supplies, but I'm just not sending any inputs associated with these
fields. I've seen a lot of people complain about django's lack of
"read only" fields, but it seems to me that being able to write your
own widgets and fields gives you total flexibility and that there's no
need for an actual "read only" field. My experience is that as soon
as I got past the basics in my project and wanted to do more complex
html/css, I never wanted to use the default rendering for any kind of
field, and read only fields are just one case of this.
In your case you say you sometimes want to create the fields as
editable and soemtimes not. In your form you could look at a GET
variable that identifies whether you want fields to be editable or not
and then either create your field with a different widget based on
that GET variable, or even modify what your widget does based on that
GET variable (ie, pass the value of the GET variable in as a parameter
to the widgets __init__() method so it can do different stuff based on
it at render time.
Anyway, hope this helps and am curious if others use this same
mechanism or if there is some alternate preferred approach.
Margie
On Dec 15, 4:01 am, Doug Blank <doug.bl...@gmail.com> wrote:
> Django users,
>
> I'm wrestling with how to best create HTML pages that can either be
> used for displaying or editing data. That is, I'd like the field's
> values to appear as text in display mode, but in their widgets when in
> edit/add mode. It appears that Django wasn't designed to do this: the
> fields always appear in their widgets (eg, text input, text area,
> etc).
>
> Is there a common technique for handling this, short of using forms
> for one, and not the other?
>
> I was thinking of a custom templatetag filter that could be used for
> every form field, like:
>
> {{ form.field_name|render_field:mode }}
>
> where render_field would either return the field's HTML widget, or
> just the value as text, based on the mode.
>
> Have I missed something, or is this a viable solution?
>
> -Doug
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
