Opened 14 years ago

Closed 12 years ago

#15620 closed Cleanup/optimization (duplicate)

ClerableFileInput should render initial value in a flexible way

Reported by: Alexey Boriskin Owned by: nobody
Component: Forms Version: dev
Severity: Normal Keywords:
Cc: sun.void@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Currently rendering of ClerableFileInput's initial value is hardcoded a bit.
It would be nice to extract generation of initial value to the method. This would allow derived classes to override only this method and not the whole render(), as shown in attached patch.

Attachments (1)

clerablefileinput_initial.patch (3.3 KB ) - added by Alexey Boriskin 14 years ago.

Download all attachments as: .zip

Change History (5)

by Alexey Boriskin, 14 years ago

comment:1 by Julien Phalip, 14 years ago

Triage Stage: UnreviewedAccepted

Why not, but it'd be preferable to have a general solution for all widgets, which incidentally has been discussed in the django-dev list recently: http://groups.google.com/group/django-developers/browse_thread/thread/7cc4279367c0a3f0

comment:2 by Julien Phalip, 14 years ago

Resolution: duplicate
Status: newclosed

Closing in favour of #15667 which is taking a holistic approach to customizing widget rendering.

comment:3 by Alexey Boriskin, 12 years ago

Cc: sun.void@… added
Easy pickings: unset
Resolution: duplicate
Severity: Normal
Status: closedreopened
Type: Cleanup/optimization
UI/UX: unset

#15667 is still open now, in 16 months after closing this ticket. So I want to reopen my tiny ticket to solve my tiny problem while the big change in widget rendering is still work-in-progress and there are chances that it will not end up as a commit in a near future.

comment:4 by Luke Plant, 12 years ago

Resolution: duplicate
Status: reopenedclosed

Sorry, I understand why you are re-opening, but I'm going to close again.

This isn't actually a 'tiny' ticket. There are two possibilities: 1) either we add documentation, in which case this new method becomes public API, which we can't change without a full deprecation cycle, which usually lasts several years, or 2) we leave it as it is without docs, which means that your problem is not really solved - "docs or it doesn't exist". Without docs, we are free to remove the method, and almost certainly will we revise widget rendering. It really doesn't make sense for us to build in customisation for one tiny part of one widget, and commit to maintaining that.

The alternative to this patch is that you override the whole of the render() method, which will work fine.

Note: See TracTickets for help on using tickets.
Back to Top