On Tue, Dec 15, 2009 at 5:45 PM, Margie Roginski
<margierogin...@yahoo.com> wrote:
> 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
Thanks Margie for this example. I may come to something similar to
this, but for the time being I think I'll just put a filter in the
template. That way, I'll have all of the elements there (errors,
display information) for all of the modes (display, edit, and add).
I'll see how far I can go with this method before having to resort to
a more substantial widget-swap.
It does seem that this is an area of Django that could use some thinking...
-Doug
>
>
> 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.
>
>
>
--
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.
