Lebe ein Haml-Leben mit Django1.8 + Jinja2 + hamlish-jinja (Python3)

Ham mit Django hat HamlPy, aber Python3 unterstützt es wahrscheinlich nicht. Tatsächlich scheint Python3 nicht viele Optionen zu haben, und ich fand, dass Hamlish-Jinja, das ziemlich tot ist, eine gute Idee ist.

hamlish-jinja ist nur eine haml-ish-Syntax, nicht Haml, aber ich hatte das Gefühl, dass ich mit Pythonic ziemlich zufrieden sein könnte. Ich denke, die Lernkosten sind fast 0! https://github.com/Pitmairen/hamlish-jinja

Nun, um das zu tun, muss ich Jinja2 für die Template-Engine verwenden, aber nun, es ist eine seltsame Geschichte, das zu ändern, aber ich mag Jinja2 nur, nicht für Haml, Ich ändere es, indem ich sage, dass ich Schreine und Tempel mag.

Was ich getan habe, um Folgendes zu verwenden.

Verwenden Sie Jinja2

http://qiita.com/ryu22e/items/e50f8a3fbd6fe836c1b4 Die Einstellungsmethode um die Vorlage hat sich seit 1.8 erheblich geändert! !! !! !! Es scheint auch, dass Jinja2 leicht eingeführt werden kann! !! !! !! !! Der Versuch, kleine Dinge zu tun, ist jedoch ziemlich schwierig, so dass pip django-jinja es wie immer viel einfacher machen kann. Die Einstellmethode ist ebenfalls detailliert. Mit match_regex können Sie abhängig von der URL wechseln, welches Backend verwendet werden soll. Also ich denke das ist in Ordnung. http://niwinz.github.io/django-jinja/

Hamlish-Jinja setzen

pip install hamlish-jinja

So sieht meine Einstellung.py so aus.

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',
            ],  
        },
    },
]

Wenn Sie nun XXX.haml in Ihr übliches Vorlagenverzeichnis einfügen und XXX.haml in der Ansicht angeben, funktioniert dies normal.

%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' 

Wie schön.

Hamlish-jinja allein hat jedoch keinen Mechanismus, um es zuerst in eine jinja-Vorlage zu kompilieren, so dass es wahrscheinlich schwierig ist, es so wie es ist in Produktion zu bringen. Aus diesem Grund habe ich mich für den Caching-Mechanismus von jinja2 entschieden. Wenn Sie es mit Jinjas Bytecode zwischenspeichern, spielt es keine Rolle, wie haml aussieht. Sollte sein.

Jetzt das.

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'),
        },
    },
 ...

Dateien werden entsprechend im angegebenen Cache-Verzeichnis gespeichert. Es ist gut, weil der Zeitstempel der Datei nur aktualisiert wird, wenn haml aktualisiert wird.

Das ist es.