feature request: add a method to Fields that is used to render the field as read-only

[nickname123]

It is possible to override the default widget that is used to render a custom model field... however the hidden_widget is more difficult. The only way appears to be on a per model basis by changing the widget in the model admin. This can be very difficult/impractical when inheriting models that make use of the custom field with the field set to readonly in the model admin.

For example, a simple field that uses a custom widget:

class CustomFileWidget(forms.FileInput):
	return mark_safe(u"CustomFileWidget was used: %s" % super(CustomFileWidget, self).render(name, value, attrs))
	
class CustomFileFormField(forms.FileField):
    def __init__(self, *args, **kwargs):
        kwargs['widget'] = CustomFileWidget
        super(CustomFileFormField, self).__init__(*args, **kwargs)
        
class CustomFileField(models.FileField):
    def formfield(self, **kwargs):
        return super(CustomFileField, self).formfield(form_class=CustomFileFormField,**kwargs)

However, there does not appear to be a kwarg for hidden_widget and using something like the following will not work:

class CustomFileFormField(forms.FileField):
    hidden_widget = CustomFileWidget
    widget = CustomFileWidget
class CustomFileField(models.FileField):
    def formfield(self, **kwargs):
        return super(CustomFileField, self).formfield(form_class=CustomFileFormField,**kwargs)

[Greg Turner]

The admin app doesn't render hidden_widget at all, it just displays readonly fields (using getattr(modelinstance, fieldname)). AFAICS hidden_widget is only used by form previews and form wizards for holding on to copies of fields that were entered in an earlier view.

If you are asking for a customised way to render a read-only field, then it might be helpful to know that you can pass a callable to readonly_fields that renders the result you want.

class Song(models.Model):
    band = models.ForeignKey(Band)
    title = CustomModelField(max_length=100)
    
    def rendertitle(self):
        return "A custom rendering of %s" % self.title

class SongAdmin(admin.ModelAdmin):
    exclude = ('title',)
    readonly_fields = ('rendertitle', )

[nickname123]

Replying to cogat:

The admin app doesn't render hidden_widget at all, it just displays readonly fields (using getattr(modelinstance, fieldname)). AFAICS hidden_widget is only used by form previews and form wizards for holding on to copies of fields that were entered in an earlier view.

If you are asking for a customised way to render a read-only field, then it might be helpful to know that you can pass a callable to readonly_fields that renders the result you want.

class Song(models.Model):
    band = models.ForeignKey(Band)
    title = CustomModelField(max_length=100)
    
    def rendertitle(self):
        return "A custom rendering of %s" % self.title

class SongAdmin(admin.ModelAdmin):
    exclude = ('title',)
    readonly_fields = ('rendertitle', )

Wouldn't it be a better idea (in the future) to use a widget to render the readonly value so that the default appearance can be overridden? Using a field like that may be nice in some situations, but it doesn't work well for my use case.

I don't think it would work well with any abstract model that is used repeatedly because you have to remember to add the callable to readonly_fields in every model's admin entry that inherits it. And also for admin inlines.

[Greg Turner]

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.

[Greg Turner]

I'll have a crack at this.

[nickname123]

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

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)

[nickname123]

Replying to cogat:

I'll have a crack at this.

Cool =).

[nickname123]

A "to readonly html string" method on the field is a better idea. I misread your suggestion somewhat earlier. Like I said above, I hadn't put too much thought into the idea because I wasn't sure how other people would react to the feature request. Glad you gave some input =).

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Aymeric Augustin]

Revert accidental batch modification.

[Jacob]

I don't really like the idea of using a widget to render readonly fields, it just seems like overkill.