Ereditarietà modello Django: quanti livelli e quale pagina rendere

Question

Mi piacerebbe avere qualche consiglio nella costruzione di livelli di template django.

Leggendo i documenti, non capisco come creare una struttura gerarchica di modelli con più di 2 livelli.

Per esempio, vorrei creare 3 livelli di ereditarietà:

base.html 
    └── base_level2.html 
      ├── level2_level3_1.html 
      └── level2_level3_2.html 

Questo è il mio codice:

• base.html

  First level 
  {% block level2 %}{% endblock %} 
  

• base_level2.html

  {% extends "base.html" %} 
  {% block level2 %} 
      Second level 
      {% block level3_1 %}{% endblock %} 
      {% block level3_2 %}{% endblock %} 
  {% endblock %} 
  

• level2_level3_1.html

  {% extends "base_level2.html" %} 
  {% block level3_1 %} 
      Third level, part 1 
  {% endblock %} 
  

• level2_level3_2.html

  {% extends "base_level2.html" %} 
  {% block level3_2 %} 
      Third level, part 2 
  {% endblock %} 
  

• views.py:

  def myView(request): 
      return render_to_response('level2_level3_1.html', {}, context_instance=RequestContext(request)) 
  

In questo modo posso vedere quanto segue su il mio browser:

First level 
Second level 
Third level, part 1 

E questo è logico perché ho chiamo render_to response solo su level2_level3_1.html.

Ovviamente, se chiama level2_level3_2.html, ricevo il messaggio Third level, part 2 ma non lo Third level, part1.

Come risolvere questo? E 'un buon approccio? Ho strutturato roba in questo modo perché i miei modelli reali sono molto grandi, molte linee di codice, quindi vorrei mantenere un po 'di ordine. Qualsiasi consiglio sarà apprezzato.

Answer 1

È difficile dire se è una buona o una cattiva idea o no senza conoscere la funzionalità specifica dei modelli, ma la mia reazione immediata è che si sta cercando di organizzare oltre i modelli. Penso che la maggior parte delle persone ti spingerebbe lontano da un sistema a più livelli perché rende più difficile apportare piccole modifiche nel sito web e più difficile tenere traccia di dove sono le cose. dalla Zen di Python:

piatto è meglio di annidata

La raccomandazione per un sistema a 3 livelli in Two Scoops of Django va in questo modo:

1. Ogni applicazione ha un base_<app_name>.html modello. I modelli di base a livello di app condividono un genitore comune, base.html.
2. I modelli all'interno di app condividono un modello genitore base_ <app_name> .html.
3. qualsiasi modello allo stesso livello base.html eredita base.html

e per il vostro schema di denominazione, potrebbe assomigliare a questo:

| Templates/ 
    |--base.html 
    |--someothertemplate.html # extends base.html 
    |--level2/ 
    |----base_level2.html  # extends base.html 
    |----level2_1.html  # extends base_level2.html 
    |----level2_2.html  # extends base_level3.html 

EDIT: e non c'è alcuna reale motivo:

Second level 
    {% block level3_1 %}{% endblock %} 
    {% block level3_2 %}{% endblock %} 

dove ciascun blocco fa riferimento al contenuto di un modello. è possibile semplificare che a un isolato come

{% block level3 %}{% endblock level3%} 

e poi in ognuno dei modelli level3, rinominare i blocchi di conseguenza

Answer 2

non

Probabilmente il miglior modo di farlo, ma si potrebbe utente includehttps://docs.djangoproject.com/en/dev/ref/templates/builtins/#include

qualcosa di simile per base_level2.html

{% extends "base.html" %} 
{% block level2 %} 
Second level 
{% include "level2_level3_1.html" %} 
{% include "level2_level3_2.html" %} 
{% endblock %} 

non ho testato questo, quindi non so che funziona.

e btw:

Il includono tag deve essere considerato come un'implementazione di “rendere questo subtemplate e comprendono il codice HTML”, non come “analizzare questo subtemplate e comprendere il suo contenuto come se fosse parte della genitore". Ciò significa che non esiste uno stato condiviso tra i modelli inclusi: ogni inclusione è un processo di rendering completamente indipendente.