... | ... | @@ -129,7 +129,7 @@ Sistemas de template como o do Django existem em praticamente todos os framework |
|
|
Existem vários motivos de otimização para eles existirem, mas isso não é importante agora.
|
|
|
Ele forçam separação entre o processamento dos dados e a apresentação deles, forçam uma organização do código. Mas isso também restringe o que podemos fazer lá, dentro de templates não se pode escrever código arbitrário, só se pode usar as funções dos templates, tags e filters. Mas tente manter a separação do MVC, passe arrays pro template, cuide deles lá.
|
|
|
|
|
|
É razoavelmente comum em algum ponto do projeto precisar [escrever o seu próprio](https://docs.djangoproject.com/en/1.11/howto/custom-template-tags/) template_tag ou filter.
|
|
|
É razoavelmente comum em algum ponto do projeto precisar [escrever o seu próprio](https://docs.djangoproject.com/en/1.11/howto/custom-template-tags/) template_tag ou filter. Somente em último caso faça um processamento mirabolante nos dados com na view antes de enviar pro template.
|
|
|
|
|
|
|
|
|
### template como segurança
|
... | ... | @@ -149,4 +149,8 @@ def view(request): |
|
|
<head>
|
|
|
{{ title }}
|
|
|
</head>
|
|
|
``` |
|
|
\ No newline at end of file |
|
|
```
|
|
|
|
|
|
Ele por padrão vai fazer isso para html, existem situações em que você deve usar o mesmo esquema para javascript também.
|
|
|
|
|
|
É possível burlar isso, desativar o autoescape. Mas evite também. O exemplo acima (usar python pra montar o html) é totalmente contrário às boas práticas e prefira [escrever um filter](https://docs.djangoproject.com/en/1.11/howto/custom-template-tags/) com a tag safe. Chamar mais gente pra discussão também é uma boa ideia. |
|
|
\ No newline at end of file |