En effet l'include n'est pas mal ni inadapté pour une menu. Néanmoins
la manière standard en django de le faire est (sauf cas spécifique
dynamique très particulier):
- Un fichier base.html qui contient:
header
{% block menu %}
html du menu par default sur toute les pages
{% endblock %}
footer
- un fichier bidule.html qui fait:
extends base.html
code html normal
- et dans le cas d'un fichidr qui a besoin d'un menu particulier:
truc.html:
extends base.html
{% block menu %}
code du menu particulier qui override le précédent
{% endblock %}
reste du code html normal
Normalement ceci couvre 99% des cas de menus.
Le sam. 14 juil. 2012 18:48:04 CEST, Christophe Narbonne a écrit :
> Kevin propose une réponse juste et pertinante, néanmoins, dans ton cas
> de menu,
> l'include ne me parait ni mal ni innadapté.
>
> Pour ma part, il m'arrive de l'utiliser pour le rendering de ligne de
> tableaux complexe ou il m'arrive de rafraichir en ajax des lignes
> individuelles.
>
> Donc, à ta place ton application d'aiguillage, ton menu, si tu le veux
> générique et réutilisabe doit avoir pour paramettre une liste
> d'applications ou de templates à inclures, je dirais d'application.
>
> Tu peux imposer la contrainte d'avoir un template
> {{nom_de_l'app}}/menu_part.html qui n'hériterai pas de base.html.
>
> Comme include attends un string, tu peux facilement itérer sur la
> liste des apps et inclure ça.
>
> Si c'est ce que tu veux faire, le plus compliqué maintenant c'est
> d'avoir un bon rendu avec un nombre d'application dans le menu
> dynamique, bonne chance.
>
>
> 2012/7/14 Kevin Samuel <[email protected]
> <mailto:[email protected]>>
>
> Bonjour,
>
> Il va être dur de vous aider sans avoir le détail de tout le code.
>
> Dans tous les cas:
>
> - "include" est rarement la solution. La plupart des structures de
> template en Django utilisent "extends". "include" prend un template,
> fais un render dessus, et l'insère là où il y a le tag alors que
> "extends" fait un render sur le template courrant, et l'enrobe dans le
> template qu'il étend.
> - je suis 100% pour structurer son projet en plein de sous apps, mais
> il ne faut pas tomber dans l'abus. Je n'ai pas la main sur le code
> donc
> je ne peux pas juger, mais est-il indispensable d'avoir deux apps
> ici ?
>
>
>
> Le sam. 14 juil. 2012 15:23:25 CEST, thomfort a écrit :
> > Bonjour,
> >
> > Je suis relativement nouveau dans le monde de Django. Je
> l'utilise pour un
> > projet personnel et je bloque à un endroit.
> >
> > Pour le moment j'ai 2 apps. La principale contient un template
> dashboard
> > qui affichera les informations des autres apps. J'ai structuré
> ma 2e apps
> > pour qu'elle aille ses propres templates pour que je puisse insérer
> > ensuite dans le dashboard de la 1ere apps. Voilà, je suis
> incapable de
> > faire cette dernière étape. J'imaginais utiliser {% include %}, mais
> > l'objet ne suit pas. Ensuite, je me suis dit que j'utiliserais
> la view de
> > ma 1ere apps pour faire mes requêtes, mais sa m'énerve au plus
> profond de
> > mettre ça à la mauvaise place.
> >
> > Auriez-vous une façons dont je pourrais structuré ça?
> >
> > Cordialement,
> > _______________________________________________
> > django mailing list
> > [email protected] <mailto:[email protected]>
> > http://lists.afpy.org/mailman/listinfo/django
>
>
> _______________________________________________
> django mailing list
> [email protected] <mailto:[email protected]>
> http://lists.afpy.org/mailman/listinfo/django
>
>
>
>
> --
> Best regards,
> Christophe Narbonne
>
> http://blogs.dotnet-france.com/christophen/
>
>
> _______________________________________________
> django mailing list
> [email protected]
> http://lists.afpy.org/mailman/listinfo/django
_______________________________________________
django mailing list
[email protected]
http://lists.afpy.org/mailman/listinfo/django
