Opened 18 years ago
Closed 18 years ago
#3280 closed defect (invalid)
Django should be HTML agnostic
Reported by: | Owned by: | Adrian Holovaty | |
---|---|---|---|
Component: | Core (Other) | Version: | |
Severity: | normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
What I think are valid reasons why Django should be HTML agnostic.
- Display code should be separate from logic. Ideally, all HTML would be in template files that one could override if need be in their own template directory, just like the admin templates. If django.forms did this, that would be great. The only consideration I can think of is what kind of load would this be to necessitate a file system call to pull in the widget template or error template?
- The argument against #1 that I've seen is usually that you can subclass Something and write your own output. But in some ways, this violates the DRY principle. The code to output a form widget, for example, is already written, and in looking at what it would take, the only change in the render() method would be the change of the HTML itself.
- Better "updatability": If there is a bug in Select(Widget) that was fixed but I have MySelect(Widget) which is mostly the same except for the HTML, I wouldn't get the fix unless I noticed and updated my code as well. Whereas if Select(Widget) pulled in a template and I overrode that template, the fix would come down just fine across all my projects.
- One of the reasons I've seen touted for the template system not having access to Python methods and having it's own language is the benefit of separating the programmer from the designer and that designers shouldn't need to know Python to create templates in Django. But they would if they want to manipulate forms or form error feedback. This should be consistent.
Note:
See TracTickets
for help on using tickets.
I appreciate the thought, but this ticket is way too broad/generic. Please give some more thought to specific examples of improvements you'd like us to make and open individual tickets for those.