Django - Philosophies and Limitations-CSDN博客

本文链接：https://blog.csdn.net/justinyun/article/details/4729518

Now that you’ve gotten a feel for the Django template language, we should point out some of
its intentional limitations, along with some philosophies behind why it works the way it works.
      More than any other component of Web applications, template syntax is highly subjec-
tive, and programmers’ opinions vary wildly. The fact that Python alone has dozens, if not
hundreds, of open source template-language implementations supports this point. Each was
likely created because its developer deemed all existing template languages inadequate. (In
fact, it is said to be a rite of passage for a Python developer to write his or her own template
language! If you haven’t done this yet, consider it. It’s a fun exercise.)
      With that in mind, you might be interested to know that Django doesn’t require you to
use its template language. Because Django is intended to be a full-stack Web framework that
provides all the pieces necessary for Web developers to be productive, many times it’s more
convenient to use Django’s template system than other Python template libraries, but it’s not
a strict requirement in any sense. As you’ll see in the upcoming section “Using Templates in
Views,” it’s very easy to use another template language with Django.
      Still, it’s clear we have a strong preference for the way Django’s template language works.
The template system has roots in how Web development is done at World Online and the
combined experience of Django’s creators. Here are a few of our philosophies:

     •    Business logic should be separated from presentation logic . Django’s developers see a
     template system as a tool that controls presentation and presentation-related logic—
     and that’s it. The template system shouldn’t support functionality that goes beyond
     this basic goal.
        For that reason, it’s impossible to call Python code directly within Django templates.
     All “programming” is fundamentally limited to the scope of what template tags can
     do. It is possible to write custom template tags that do arbitrary things, but the out-
     of-the-box Django template tags intentionally do not allow for arbitrary Python-code
     execution.
    •    Syntax should be decoupled from HTML/XML. Although Django’s template system
     is used primarily to produce HTML, it’s intended to be just as usable for non-HTML
     formats, such as plain text. Some other template languages are XML based, placing all
     template logic within XML tags or attributes, but Django deliberately avoids this limita-
     tion. Requiring valid XML for writing templates introduces a world of human mistakes
     and hard-to-understand error messages, and using an XML engine to parse templates
     incurs an unacceptable level of overhead in template processing.
    •    Designers are assumed to be comfortable with HTML code. The template system isn’t
     designed so that templates necessarily are displayed nicely in WYSIWYG editors such
     as Dreamweaver. That is too severe a limitation and wouldn’t allow the syntax to be
     as friendly as it is. Django expects template authors to be comfortable editing HTML
     directly.
    •    Designers are assumed not to be Python programmers. The template-system authors
     recognize that Web-page templates are most often written by designers, not program-
     mers, and therefore should not assume Python knowledge.
        However, the system also intends to accommodate small teams in which the templates
     are created by Python programmers. It offers a way to extend the system’s syntax by
     writing raw Python code. (More on this in Chapter 9.)
    •    The goal is not to invent a programming language. The goal is to offer just as much
     programming-esque functionality, such as branching and looping, that is essential for
     making presentation-related decisions.