2009-03-24 6 views
2

Ich habe den Code in meinem urls.py für meine generischen Ansichten;Angeben unterschiedlicher Vorlagennamen in generischen Django-Ansichten

infodict = { 
'queryset': Post.objects.all(), 
'date_field': 'date', 
'template_name': 'index.html', 
'template_object_name': 'latest_post_list', 
} 

urlpatterns += patterns('django.views.generic.date_based', 
(r'^gindex/$', 'archive_index', infodict), 
) 

So an die Adresse/gindex gehen/eine allgemeine Ansicht mit der Vorlage von ‚index.html‘ verwenden.

Aber da ich mehr generische Ansichten in diesem urlpattern haben werde, wie soll ich einen anderen Schablonennamen mit dem gleichen Infodict angeben? Ich möchte nicht viele Infodikte verwenden und den Standardnamen der Vorlage nicht verwenden.

Bitte beachten Sie, dass dies auch für den Namen des Vorlagenobjekts innerhalb von infodict gilt.

Danke für Ihre Hilfe!

Bearbeiten: Dies ist eine meiner ersten Fragen zu stackoverflow und ich bin erstaunt über die gründlichen Antworten! Ich bevorzuge den dict-Konstruktor, den ich nicht kannte. Ich finde die Verwendung der Python-Dokumentation ein bisschen schwieriger, da ich normalerweise nicht finde, wonach ich suche!

Nochmals vielen Dank für alle Antworten und verschiedene Ansätze.

Antwort

8

die dict() Konstruktor:

infodict = { 
    'queryset': Post.objects.all(), 
    'date_field': 'date', 
    'template_name': 'index.html', 
    'template_object_name': 'latest_post_list', 
} 

urlpatterns = patterns('django.views.generic.date_based', 
    url(r'^gindex/$', 'archive_index', dict(infodict, template_name='gindex.html')), 
    url(r'^hindex/$', 'archive_index', dict(infodict, template_name='hindex.html')), 
) 
+0

+1 mehr im Einklang mit dem, was gefragt wurde. –

1

Wenn Sie verschiedene Vorlagennamen für verschiedene Ansichten bereitstellen möchten, ist es in der Praxis üblich, jedem URL-Muster ein eindeutiges Wörterbuch zu übergeben. Zum Beispiel:

urlpatterns = patterns('', 
    url(r'^home/$', 'my.views.home', {'template_name': 'home.html'}, name='home'), 
    url(r'^about/$', 'my.views.about', {'template_name': 'about.html'}, name='about'), 
) 

Diese Art von Muster ist üblich und akzeptabel.

+0

-1 Dies geht nicht auf die Frage ein.Wenn das Infodikt fünf oder sechs Elemente enthält, würden Sie wirklich alle allgemeinen Parameter über jede URL in separaten Wörterbüchern duplizieren? Das würde ich sicherlich nicht tun. –

+0

Für Lesbarkeit könnte ich; vor allem, wenn sich diese Argumente in Zukunft ändern werden. –

+0

Fair genug; Der Code funktioniert und zieht -1 zurück. –

0

nicht so einfach, aber möglicherweise nützlich, wenn Sie eine ganze Reihe von verschiedenen Mustern haben die gleiche Ansicht passend:

base_dict={ 
... 
#defaults go here 
} 
def make_dict(template_name,template_object_name): 
    base_dict.update({ 
     'template_name':template_name, 
     'template_object_name':template_object_name, 
    }) 
    return base_dict 

urlpatterns += patterns('django.views.generic.date_based', 
(r'^gindex/$', 'archive_index', make_dict('index1.html','latest_poll_list')), 
(r'^hindex/$', 'archive_index', make_dict('index2.html','oldest_poll_list')), 
) 

Für viele ähnliche generische Ansichten, wird dies kondensieren Ihren Code ein klein wenig ruft, auf Kosten von ein wenig Transparenz. Wenn Sie viele Zeilen haben, die die gleichen Parameter anpassen, ist dies am einfachsten zu lesen.

Schließlich, wenn alle oder die meisten Ihrer Ansichten erfordern einige, aber nicht alle, der gleichen Informationen, nie vergessen, wie nützlich einist. Es braucht nur ein wenig mehr Arbeit als die oben genannten Lösungen, aber es verlängert sich viel besser, weil es garantiert, dass (sofern Sie die render_to_response-Verknüpfung ohne das RequestContext-Schlüsselwort verwenden) die Standardwerte für Ihre Vorlage immer verfügbar sind Ihre Ansicht oder URL-Konfig ändert sich.

+0

-1 Der "update" Code wird nicht funktionieren; Hast du es versucht? dict.update() gibt das aktualisierte dict nicht zurück, es aktualisiert das dict "in place" und gibt None zurück. Und die andere Lösung ist unnötige Ausführlichkeit, wo Sie einfach dict (infodict, blah = "blah") verwenden könnten. –

+0

Sie haben Recht. Ich denke jedoch, dass das ausführliche Beispiel schöner sein könnte, wenn Sie viele passende Muster hätten. Aber wahrscheinlich nicht so nützlich. –

0

können Sie Wrapper View-Funktionen definieren, um generische Ansichten zu parametrisieren. In Ihrem urls.py hinzufügen Muster

url(r'^/(?P<tmpl_name>\w+)/$', 'my.views.datebasedproxy') 

in Ihrer views.py hinzufügen View-Funktion

def datebasedproxy(request, tmpl_name): 
    return django.views.generic.date_based(request,otherparameters, 
    template_name=tmpl_matrix[tmpl_name]) 

wo tmpl_matrix hypothetic Liste ist, die mit dem Parameter und otherparameters Vorlage Dateinamen entspricht für andere Wörterbuch Artikel steht erforderlich für date_based Funktion

Verwandte Themen