Ho una piccola libreria templatetag relativa alla tipografia che uso su quasi tutte le pagine. In questo momento ho bisogno di caricarlo per ogni modello utilizzandoCarica una libreria di tag modello Django per tutte le viste per impostazione predefinita
{% load nbsp %}
Esiste un modo per caricarlo "globale" per tutte le viste e modelli in una sola volta? L'inserimento del tag di caricamento in un modello di base non funziona.
C'è un metodo add_to_builtins in django.template.loader. Basta passargli il nome del tuo modulo templatetags (come stringa).
from django.template.loader import add_to_builtins
add_to_builtins('myapp.templatetags.mytagslib')
Ora mytagslib è disponibile automaticamente in qualsiasi modello.
In Django 1.7 basta sostituire per from django.template.base import add_to_builtins
Perché il downvote? Questo mi ha salvato la giornata, perché la risposta accettata è superata! Il percorso di importazione è cambiato in Django 1.7. Grazie bsao! –
Questo dovrebbe essere un commento o una modifica sulla [risposta esistente] (http://stackoverflow.com/a/1185049/1075247)? Non ha senso per se stesso. – Pureferret
Cambierà con Django 1.9 rilascio.
Dal 1.9, corretto approccio sarà la progettazione di variabili di modello e filtri sotto builtins chiave di OPTIONS - vedere l'esempio di seguito:
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [],
'APP_DIRS': True,
'OPTIONS': {
'builtins': ['myapp.builtins'],
},
},
]
Dettagli: https://docs.djangoproject.com/en/dev/releases/1.9/#django-template-base-add-to-builtins-is-removed
A partire da ora (Django 1.9), questa dovrebbe essere la risposta accettata. –
''builtins': ['django.templatetags.i18n'],' oh si. –
In Django 1.9 c'è un dizionario libraries di etichette e percorsi punteggiati in Python di moduli tag modello da registrare con il motore di template. Questo può essere usato per aggiungere nuove librerie o fornire etichette alternative per quelle esistenti.
TEMPLATES = [
{
'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',
],
'libraries': { # Adding this section should work around the issue.
'custom_tags' : 'myapp.templatetags.custom_tags',#to add new tags module.
'i18n' : 'myapp.templatetags.custom_i18n', #to replace exsiting tags modile
},
},
},
]
Eccellente, grazie. –
Nota che, mentre puoi farlo, è abbastanza probabile che te ne pentirai ad un certo punto (l'ho fatto e me ne sono pentito). Rende i tuoi modelli non portabili a qualsiasi altro progetto che non sia add_to_builtins, e può rompere i test che rendono questi template (a meno che tu non assicuri che il test runner esegua anche add_to_builtins). Tutto sommato, rende le cose più fragili per un guadagno molto piccolo in termini di convenienza. –
Senza contare che qualsiasi nuovo sviluppatore sarà confuso dall'uso di un tag che non esiste nelle librerie standard, fino a quando non ti chiedono (se sei ancora in giro) o inciampare su di esso. :) Ricorda, l'esplicito è meglio di implicito. –