Django vue de charge modèle à partir de l'appel de l'application dir première

J'essaie de garder un peu le schéma cohérent de nommage sur mes modèles HTML. I. e. index.html pour le principal, delete.html pour supprimer la page et ainsi de suite. Mais le app_directories chargeur semble toujours charger le modèle de l'app qui est premier dans l'ordre alphabétique.

Est-il possible de toujours vérifier pour un match à l'appel de l'application templates répertoire?

Paramètres pertinents dans mon settings.py:

PROJECT_PATH = os.path.realpath(os.path.dirname(__file__))

TEMPLATE_LOADERS = (
    'django.template.loaders.app_directories.load_template_source',
    'django.template.loaders.filesystem.load_template_source',
)
TEMPLATE_DIRS = (
    os.path.join(PROJECT_PATH, 'templates'),
)

J'ai essayé de changer l'ordre de TEMPLATE_LOADERS, sans succès.

Modifier comme demandé par Ashok:

Dir de la structure de chaque application:

templates/
    index.html
    add.html
    delete.html
    create.html
models.py
test.py
admin.py
views.py

Dans chaque application views.py:

def index(request):
    # code...
    return render_to_response('index.html', locals())

def add(request):
    # code...
    return render_to_response('add.html', locals())

def delete(request):
    # code...
    return render_to_response('delete.html', locals())

def update(request):
    # code...
    return render_to_response('update.html', locals())
  • pouvez-vous fournir la structure de votre "templates" répertoire et un code d'exemple de la façon dont vous chargez/rendu le modèle
  • Le app_directories chargeur semble un peu trompeur pour moi. J'aurais cru qu'il serait de charger les modèles de la corriger répertoire applications, tout comme vous. Après tout, n'est-ce pas le point de django app pour être en mesure de créer des tranches séparées?
InformationsquelleAutor jmagnusson | 2010-06-22
  1. 49

    La raison pour cela est que la app_directories chargeur est essentiellement le même que l'ajout de chaque application du modèle de dossier à la TEMPLATE_DIRS, p. ex. comme

    TEMPLATE_DIRS = (
    os.path.join(PROJECT_PATH, 'app1', 'templates'),
    os.path.join(PROJECT_PATH, 'app2', 'template'),
    ...
    os.path.join(PROJECT_PATH, 'templates'),
)

    Le problème, c'est que comme vous l'avez mentionné, l'index.html vous trouverez toujours dans app1/templates/index.html au lieu de toute autre application. Il n'y a pas de solution facile grâce à la magie corriger ce problème sans modifier le app_directories chargeur et l'utilisation de l'introspection ou le passage de l'information de l'application, ce qui devient un peu compliqué. Une solution plus facile:

    • Garder votre settings.py que-est
    • Ajouter un sous-répertoire dans chaque application de modèles de dossier avec le nom de l'application
    • Utiliser les modèles dans des vues comme des 'app1/index.html" ou "app2/index.html'

    Pour un exemple plus concret:

    project
    app1
        templates
            app1
                index.html
                add.html
                ...
        models.py
        views.py
        ...
    app2
        ...

    Puis dans les vues:

    def index(request):
    return render_to_response('app1/index.html', locals())

    Vous pouvez même écrire un wrapper pour automatiser les préfixant le nom de l'application à l'ensemble de vos points de vue, et même qui pourrait être étendu à l'utilisation de l'introspection, par exemple:

    def render(template, data=None):
    return render_to_response(__name__.split(".")[-2] + '/' + template, data)

def index(request):
    return render('index.html', locals())

    L' _____nom_____.split(".")[-2] suppose que le fichier est dans un paquet, donc il tournera par exemple 'app1.vues' dans 'app1' à ajouter le nom du modèle. Cela suppose également un utilisateur de ne jamais renommer votre application sans renommer le dossier dans le répertoire des modèles, ce qui peut ne pas être une hypothèse sûre à faire et dans ce cas il suffit de coder en dur le nom du dossier dans le répertoire des modèles.

    • C'est à peu près la seule chose qui me manque de CakePHP 🙂 j'espère qu'ils vont ajouter un jour.
    • C'est une bonne solution pour une fracture à la django fonctionnalité (c'est un compromis pour une très simple-pour-étendre le système de template); mais encore, elle oblige à ajouter le "appname" dossier de votre application modèle de dossier, et 'nom' peut ne pas être celui que vous souhaitez utiliser dans votre projet...
    • C'est une belle et simple de la solution, tant qu'il n'y a pas imbriquée des applications... 😉
    • Cet ajout de nombreux modèles n'est pas plus idiomatiques pour Django. Actuellement, vous pouvez utiliser "'APP_DIRS' : True" à la place. Il récursivement comprend modèle dirs pour projet principal
    • Le paramètre "APP_DIRS": True serait pour toujours. Si le nom du modèle est le même, il a encore besoin de quelques préfixe pour rendre le modèle de chargeur pour les distinguer. Mais je me demande si je crée un sous-répertoire templates dossier à la racine, et de mettre tout ce que l'application du modèle de là, pourrait-il être une bonne solution?
    • Je pense que ce sera ok. Mais personnellement, je préfère mettre des modèles pour leurs applications pour éviter la confusion. Par exemple, si j'ai 2 applications appelé "premier" et "second" et "change_form.html' modèles pour chaque, j'en ai mis dans "first/templates/admin/change_form.html" et "second/templates/admin/change_form.html'. Mais bien sûr, cela dépend de vous. Si vous souhaitez recueillir dans 1 dossier situé à la racine puis le faire. Et dans cette situation j'aurais 'templates/first/admin/change_form.html" et "templates/second/admin/change_form.html'. Je pense que les deux solutions que ok.
    • Nous avons pour éditer ce post render_to_response méthode est obsolète depuis la version 2.0. LIEN

    InformationsquelleAutor Daniel
  2. 7

    Je sais que c'est un vieux thread, mais j'ai fait quelque chose de réutilisable, qui permet de plus simple namespacing. Vous pouvez charger la suit comme un Modèle de Chargeur. Il va trouver appname/index.html dans appname/templates/index.html.

    Gist disponible ici: https://gist.github.com/871567

    """
Wrapper for loading templates from "templates" directories in INSTALLED_APPS
packages, prefixed by the appname for namespacing.

This loader finds `appname/templates/index.html` when looking for something
of the form `appname/index.html`.
"""

from django.template import TemplateDoesNotExist
from django.template.loaders.app_directories import app_template_dirs, Loader as BaseAppLoader

class Loader(BaseAppLoader):
    '''
    Modified AppDirecotry Template Loader that allows namespacing templates
    with the name of their app, without requiring an extra subdirectory
    in the form of `appname/templates/appname`.
    '''
    def load_template_source(self, template_name, template_dirs=None):
        try:
            app_name, template_path = template_name.split('/', 1)
        except ValueError:
            raise TemplateDoesNotExist(template_name)

        if not template_dirs:
            template_dirs = (d for d in app_template_dirs if
                    d.endswith('/%s/templates' % app_name))

        return iter(super(Loader, self).load_template_source(template_path,
                template_dirs))
    • Eh bien, il fonctionne exactement comme ` django.de modèle.les chargeurs.app_directories.Loader " dans Django 1.5.x. Et le problème est toujours pas résolu.
    InformationsquelleAutor hidde-jan
  3. 4

    La app_loader recherche de modèles au sein de vos applications afin qu'ils sont spécifiés dans votre INSTALLED_APPS. (http://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types).

    Ma suggestion est de faire précéder le nom de votre fichier de modèle avec le nom de l'application pour éviter ces conflits de noms.

    Par exemple, le modèle dir pour app1 ressemblerait à:

    templates/
    app1_index.html
    app1_delete.html
    app1_add.html
    app1_create.html
    • Merci Chris ! après un long temps de recherche, la réponse a été pour moi - l'application n'a pas été inscrite dans INSTALLED_APPS, par conséquent, il était seulement à la recherche dans la base de modèles de dossier, pas le dossier local de l'application. Pour moi, c'est parce que mon settings.py et mon local_settings.py étaient hors de synchronisation car le seul de la settings.py la version est contrôlée, après un pull et mise à jour il y a une nouvelle application, mais mon local_settings.py "écrasait" il.
    InformationsquelleAutor Chris Lawlor