Opened 8 years ago

Closed 8 years ago

#3280 closed defect (invalid)

Django should be HTML agnostic

Reported by: Rob Hudson <treborhudson@…> Owned by: adrian
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: UI/UX:

Description

What I think are valid reasons why Django should be HTML agnostic.

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

Change History (1)

comment:1 Changed 8 years ago by adrian

  • Resolution set to invalid
  • Status changed from new to closed

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.

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