Re: Using Forms to display and edit?

[Doug Blank]

On Tue, Dec 15, 2009 at 5:45 PM, Margie Roginski
 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  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 

Re: Using Forms to display and edit?

[Margie Roginski]

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  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.

Using Forms to display and edit?

[Doug Blank]

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.