Perché alcuni includono in Django le stringhe e altri nomi variabili?

Question

Riferendosi al Django Book, chapter 3:

from django.conf.urls import patterns, include, url 

# Uncomment the next two lines to enable the admin: 
# from django.contrib import admin 
# admin.autodiscover() 

urlpatterns = patterns('', 
    # Examples: 
    # url(r'^$', 'mysite.views.home', name='home'), 
    # url(r'^mysite/', include('mysite.foo.urls')), 
    # url(r'^admin/doc/', include('django.contrib.admindocs.urls')), 
    # url(r'^admin/', include(admin.site.urls)), 
) 

Che cosa determina il motivo per cui una cosa è incluso come una stringa, e un altro come variabile normale? Perché admin.site.urls ma non 'admin.site.urls'? Tutti gli altri include s sono inclusi come stringhe ... Non vedo alcun modello logico qui.

Answer 1

Prima di tutto, il primo schema ('mysite.views.home' -> una funzione di visualizzazione) è deprecato in 1.8: ha portato a tutti i tipi di problemi.

Per il resto, in genere funziona sia. 'mysite.foo.urls' è stato risolto per includere i modelli nel modulo mysite.foo.urls, ma from mysite.foo import urls as foo_urls; include(foo_urls) funziona pure. Importazioni basati su stringhe sono per lo più un manufatto storico che non è stato rimosso, ma è conveniente e non hanno alcuna inconvenienti reali come il modulo viene immediatamente importato (e quindi, qualsiasi ImportError è facilmente riconducibile ai config URL).

admin.site.urls è diverso, perché admin.site.urls è non un modulo, ma site è un oggetto e urls è un attributo. Per questo motivo, le importazioni basate su stringhe di admin.site.urls non funzioneranno e sarà necessario utilizzare il secondo metodo.

Come ultima nota, l'avvertimento all'inizio del Django Book, affermando che è estremamente fuori moda, non è aggiornato. Sarebbero preferibili risorse più aggiornate, come la documentazione ufficiale (una delle migliori documentazioni ufficiali che conosca).

Answer 2

Se si sta passando a include() un elenco di istanze url(), non si utilizza una stringa (vedere Include() docs e Including other URLconfs docs). Nell'esempio degli URL di amministrazione, admin.site.urls fa riferimento a un elenco di istanze di url. Vedere il metodo get_urls nel numero source code (che fornisce l'elenco delle istanze url a cui fa riferimento admin.site.urls).

def get_urls(self): 
    ... 
    # Admin-site-wide views. 
    urlpatterns = [ 
     url(r'^$', wrap(self.index), name='index'), 
     url(r'^login/$', self.login, name='login'), 
     url(r'^logout/$', wrap(self.logout), name='logout'), 
     url(r'^password_change/$', wrap(self.password_change, cacheable=True), name='password_change'), 
     url(r'^password_change/done/$', wrap(self.password_change_done, cacheable=True), 
      name='password_change_done'), 
     url(r'^jsi18n/$', wrap(self.i18n_javascript, cacheable=True), name='jsi18n'), 
     url(r'^r/(?P<content_type_id>\d+)/(?P<object_id>.+)/$', wrap(contenttype_views.shortcut), 
      name='view_on_site'), 
    ] 

Answer 3

Hai ragione, questo è stato un po 'di confusione. Lo hanno cambiato in Django 1.8, quindi ora supportano solo le variabili normali.

Per saperne di più su questo in Django 1.8 release note.

Answer 4

È necessario mettere un percorso con una stringa nella funzione include(). Ma admin.site.urls è come una stringa, perché all'inizio del codice, si dispone di un'importazione

Answer 5

Dalla documentazione Django 1.8, include() può prendere come argomento un modulo O un nome di modulo

https://docs.djangoproject.com/en/1.8/ref/urls/#include

la linea

from django.contrib import admin 

importa il modulo di amministrazione. Quindi, può essere usato direttamente come argomento per includere. Gli altri metodi include() hanno argomenti stringa che nominano altri URLconf.