Vivez une vie de Haml avec Django1.8 + Jinja2 + hamlish-jinja (Python3)

Ham avec Django a HamlPy, mais Python3 ne le prend probablement pas en charge. En fait, Python3 ne semble pas avoir beaucoup d'options, et j'ai pensé que hamlish-jinja, qui est plutôt mort, est une bonne idée.

hamlish-jinja est juste une syntaxe haml-ish, pas Haml, mais j'ai senti que je pourrais être assez heureux avec Pythonic. Je pense que le coût d'apprentissage est presque nul! https://github.com/Pitmairen/hamlish-jinja

Eh bien, pour cela, je dois utiliser Jinja2 pour le moteur de modèle, mais bon, c'est une histoire étrange à changer pour cela, mais j'aime Jinja2 purement, pas pour Haml, Je change cela en disant que j'aime les sanctuaires et les temples.

Ce que j'ai fait pour utiliser ce qui suit.

Utilisez Jinja2

http://qiita.com/ryu22e/items/e50f8a3fbd6fe836c1b4 La méthode de réglage autour du modèle a considérablement changé depuis la 1.8! !! !! !! De plus, il semble que Jinja2 puisse être facilement introduit! !! !! !! !! Cependant, essayer de faire de petites choses est assez difficile, donc après tout, comme d'habitude, pip django-jinja peut rendre les choses beaucoup plus faciles. La méthode de réglage est également détaillée. Avec match_regex, vous pouvez changer le backend à utiliser en fonction de l'URL. Donc je pense que c'est bien. http://niwinz.github.io/django-jinja/

hamlish-jinja mis

pip install hamlish-jinja

Donc, mon setting.py ressemble à ceci.

from django_jinja.builtins import DEFAULT_EXTENSIONS
from hamlish_jinja import HamlishExtension

TEMPLATES = [ 
    {   
        "BACKEND": "django_jinja.backend.Jinja2",
        'DIRS': [], 
        'APP_DIRS': True,
        'OPTIONS': {
            'match_regex': r"^(?!admin/).*",
            'match_extension': ".haml",
            'extensions': DEFAULT_EXTENSIONS + [HamlishExtension]
        },  
    },  
    {   
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [], 
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],  
        },
    },
]

Maintenant, si vous mettez XXX.haml dans votre répertoire de modèles habituel et spécifiez XXX.haml dans la vue, cela fonctionnera normalement.

%html
  %head
    %meta charset='utf-8'
    %meta name='viewport' content='width=device-width'
    %meta name='format-detection' content='telephone=no'
    %meta name='description' content={{description}}
    %meta name='keywords' content={{keywords}}
    %title << {{title}}
    %script type='text/javascript' src='http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js' 

Comme c'est gentil.

Cependant, hamlish-jinja seul n'a pas de mécanisme pour le compiler d'abord dans un modèle jinja, il est donc probablement difficile de le mettre en production tel quel. Par conséquent, j'ai décidé d'utiliser le mécanisme de mise en cache de jinja2 lui-même. Si vous le cachez avec le code octet de jinja, peu importe à quoi ressemble le haml. Devrait être.

Maintenant ça.

from jinja2 import FileSystemBytecodeCache
...
...
TEMPLATES = [
    {
        "BACKEND": "django_jinja.backend.Jinja2",
        'DIRS': [],            
        'APP_DIRS': True,      
        'OPTIONS': {           
            'match_regex': r"^(?!admin/).*",
            'match_extension': ".haml", 
            'extensions': DEFAULT_EXTENSIONS + [HamlishExtension],
            'bytecode_cache': FileSystemBytecodeCache(directory=os.path.join(BASE_DIR, 'project/cache'), pattern='%s.cache'),
        },
    },
 ...

Les fichiers s'accumuleront dans le répertoire de cache spécifié le cas échéant. C'est bien car l'horodatage du fichier n'est mis à jour que lorsque le haml est mis à jour.

C'est tout.