Tornado template engine always has a pit, sometimes you may feel that does not affect the normal use, but obsessive-compulsive disorder is unbearable: the template will remove the space before and after each line.
The final page is this:
No indentation really affects the mood well, especially for a python developer.
Some foreign q&a have some discussion about this situation, which refers to more compress_whitespace. Finding a issue:https://github.com/tornadoweb/tornado/issues/178 in GitHub is a matter of complaining about whitespace characters. Whitespace characters are removed in <pre>, causing the code label "<pre>" to go wrong.
Let's take a look at the tornado code, which is the constructor for the template class:
Copy Code code as follows:
def __init__ (self, template_string, name= "<string>", Loader=none,
Compress_whitespace=none, Autoescape=_unset):
Self.name = Name
If Compress_whitespace is None:
Compress_whitespace = Name.endswith (". html") or \
Name.endswith (". js")
There is a compress_whitespace parameter that will compress_whitespace true when name (template address) ends with. html or. js.
In fact, finally, in the Generate function, the code that handles spaces:
Copy Code code as follows:
If Writer.compress_whitespace and "<pre>" not in value:
Value = Re.sub ([\ t]+), "", value)
Value = Re.sub (r "(\s*\n\s*)", "\ n", value)
Enter this if statement when the Compress_whitespace is true and there is no "<pre>" in the HTML. "<pre>" This I estimate is to solve the above issue use, but obviously is a very pythonic way.
After some analysis, it can be found that there are some ways to avoid the "indentation" is removed:
In the 1.Template constructor, the Compress_whitespace=false is passed in.
2. Add "<pre>" to the template.
3. The template file is not. html or. js suffix, which can be. htm or. TPL, and so on.
4. Modify the core library code.
The 2nd method is certainly the worst, and it is not possible to change the template to indent the problem. The 3rd approach can only be counted as a trade-off to avoid trouble rather than trouble, not my style, and the suffix changes often affect the code highlighting and code completion in the editor. The 1th approach should be the best, but in fact, the template we call in controller is done using render () or render_string (), which encapsulates the template object creation process. We have no access to the template constructor, so we can't control the value of the compress_whitespace.
So I hope the official can make changes, so that the code can be pythonic.
Here I use the 4th method, directly to modify the tornado core code, these words are commented out: