Integracja Mako z podsystemem backendu szablonów Django 1.8

Django 1.8 wprowadziło obsługę wielu silników szablonów, znaczącą zmianę architektoniczną, która pozwoliła programistom wyjść poza domyślny Django Template Language. Funkcja ta była finansowana przez społeczność poprzez kampanię Indiegogo i stanowiła odpowiedź na problemy wydajnościowe ze złożonymi szablonami.

Nowy system backendu szablonów wymaga implementacji niestandardowej klasy dziedziczącej po BaseEngine. Klasa ta musi zapewniać dwie metody: from_string() do bezpośredniej kompilacji kodu szablonów oraz get_template() do ładowania szablonów według nazwy. Obie metody zwracają obiekty Template z sygnaturą render(context, request).

Krytyczny szczegół implementacyjny dotyczy prawidłowej obsługi inicjalizacji BaseEngine. Klasa nadrzędna sprawdza, czy wszystkie parametry konfiguracyjne zostały wykorzystane, więc programiści muszą jawnie skopiować i usunąć słownik OPTIONS przed wywołaniem konstruktora nadklasy.

Procesory kontekstu to kolejna kwestia do rozważenia. W przeciwieństwie do natywnego silnika szablonów Django, alternatywne backendy jak Jinja2 i Mako nie obsługują natywnie procesorów kontekstu. Implementacja niestandardowych backendów wymaga ręcznego stosowania procesorów kontekstu w metodzie render opakowania szablonu.

Implementacja Mako pokazuje tworzenie klasy bazowej do wielokrotnego użytku, którą mogą rozszerzać inne backendy szablonów. Ta klasa bazowa obsługuje stosowanie procesorów kontekstu i wyodrębnianie OPTIONS, podczas gdy konkretne implementacje silników skupiają się na inicjalizacji silnika i tłumaczeniu wyjątków.

Wybór szablonu staje się nieco mniej wydajny, gdy skonfigurowanych jest wiele backendów, ponieważ Django skanuje każdy zarejestrowany backend. Jednak moduł django.template.loader udostępnia parametr using, który umożliwia jawne określenie backendu, bez przeszukiwania wszystkich backendów.