Django admin: Qual è il modo migliore per aggiungere una vista elenco personalizzato?

Question

Voglio fornire una visualizzazione personalizzata in admin molto simile a changelist_view(), ma senza i collegamenti alla vista modulo di modifica. Gli utenti saranno in grado di selezionare gli elementi dell'elenco e applicare azioni, proprio come in forma di elenco cambiamento, ma non avranno accesso al modulo di modifica.

Credo che la struttura della classe ModelAdmin dovrebbe essere simile a questo:

class ProductAdmin(admin.ModelAdmin):
    def get_urls(self):
        urls = super(ProductAdmin, self).get_urls()
        urls += patterns('',
            (r'^selectlist/$', self.selectlist_view)
        )
        return urls

    def selectlist_view(self):
        return render_to_response(...)

La vista da restituire è molto simile a ModelAdmin.changelist_view(). Qual è il modo migliore e DRY per fare questo?

Answer 1

Il seguente ModelAdmin personalizzato è la soluzione migliore che potevo venire in mente finora:

class UserModelAdmin(ModelAdmin):
    def get_urls(self):
        urls = super(UserModelAdmin, self).get_urls()
        info = self.model._meta.app_label, self.model._meta.module_name
        select_list_url = patterns('',
            url(r'^selectlist/$', self.selectlist_view, 
                name='%s_%s_select' % info)
        )
        return select_list_url + urls

    def selectlist_view(self, request, extra_context=None):
        temp_list_display_links = self.list_display_links
        self.list_display_links = (None, )
        response = self.changelist_view(request, extra_context)
        self.list_display_links = temp_list_display_links
        return response

Answer 2

Io in realtà non so perché, ma personalmente tendo a Override (o ampliare) l'elenco cambiamento modello per un particolare modello, invece di monkeypatching ModelAdmin.

A CURA:

Grazie, ma la personalizzazione bisogno io che non può essere fatto solo sovrascrivendo il modello. ad esempio la visualizzazione di un set di query diversa, ecc

Per visualizzare un set di query diverso è possibile overrride ModelAdmin.queryset ().

anche la non dovrebbe essere in grado di modificare gli elementi elencati. se sovrascrivo il modello, l'utente non vedrà un link al modulo di modifica, ma può ancora accedere al modulo e modificare digitando l'url se riesce a indovinare l'URL per la forma, il che sarebbe un buco di sicurezza.

Perché non solo rimuovere l'autorizzazione di modifica da parte degli utenti in questione? È possibile ignorare le "Aggiungi" e vedute "cambiamento", così:

class SomeModelAdmin(admin.ModelAdmin):
    ...
    def change_view(self, request, object_id, extra_context=None):
        return render_to_response('forbiden_operation.html', dict(op='edit'))
    def ModelAdmin.add_view(self, request, form_url='', extra_context=None):
        return render_to_response('forbiden_operation.html', dict(op='add'))

Questi sono i ganci "ufficiali", meno soggette a fratture in futuro.

Anche ricordare "The Zen of Admin":

Al suo interno, interfaccia di amministrazione di Django è stato progettato per una sola attività:

Gli utenti attendibili di editing di contenuti strutturati.

Sì, è estremamente semplice - ma questa semplicità si basa su tutta una serie di ipotesi. L'intera filosofia della interfaccia di amministrazione di Django deriva direttamente da questi presupposti, quindi cerchiamo di scavare nel sottotesto di questa frase in sezioni che seguono. “Utenti fidati ...”

L'interfaccia di amministrazione è stato progettato per essere utilizzato da persone che si, lo sviluppatore, la fiducia. Questo non significa solo “le persone che sono stati autenticati”; vuol dire che Django presuppone che i vostri editori di contenuti possono essere di fiducia per fare la cosa giusta.

Questo a sua volta significa che non c'è processo di approvazione per la modifica dei contenuti - se vi fidate gli utenti, nessuno ha bisogno di approvare delle loro modifiche. Un'altra implicazione è che il sistema di autorizzazione, mentre il potente, non ha il supporto per limitare l'accesso su una base per-oggetto al momento della stesura. Se vi fidate qualcuno a modificare le proprie storie, di fiducia che l'utente non alle storie di modifica di chiunque altro senza permesso.

“... editing ...”

Lo scopo principale di interfaccia di amministrazione di Django è quello di lasciare i dati utenti di apportare modifiche. Questo sembra ovvio in un primo momento, ma ancora una volta ha delle ripercussioni sottili e potenti.

Per esempio, anche se l'interfaccia di amministrazione è molto utile per la revisione dei dati (come appena descritto), non è stato progettato con questo scopo in mente. Ad esempio, si noti la mancanza di un permesso “può vedere” (si veda il Capitolo 12). Django presume che se le persone sono autorizzati a visualizzare il contenuto in l'interfaccia di amministrazione, sono anche permesso di modificarla.

Un'altra cosa più importante da notare è la mancanza di qualcosa di anche lontanamente si avvicina “del flusso di lavoro.” Se un determinato compito richiede una serie di passaggi, non c'è alcun supporto per far rispettare che quei passi essere fatto in un ordine particolare. interfaccia di amministrazione di Django si concentra sulla modifica, non sulle attività di editing circostanti. Questo scanso di flusso di lavoro deriva anche dal principio di fiducia:. La filosofia del interfaccia di amministrazione è che il flusso di lavoro è una questione personale, non qualcosa da attuare nel codice

Infine, si noti la mancanza di aggregazione nella interfaccia di amministrazione. Cioè, non c'è alcun supporto per la visualizzazione di totali, medie, e così via. Anche in questo caso, l'interfaccia di amministrazione è per la modifica -. Ci si aspetta che bisogna scrivere visualizzazioni personalizzate per tutto il resto

“... contenuto strutturato”

Come per il resto del Django, l'interfaccia di amministrazione che si vuole lavorare con dati strutturati. Così, supporta solo la modifica dei dati memorizzati nei modelli Django; per altri scopi, come ad esempio i dati memorizzati su un file system, avrete bisogno di visualizzazione personalizzatas.

Full Stop

Dovrebbe essere chiaro ormai che l'interfaccia di amministrazione di Django non cerca di essere tutto per tutti i popoli; invece, abbiamo scelto di concentrarsi strettamente su una cosa e fare quella cosa molto bene.

Quando si tratta di estendere l'interfaccia di amministrazione di Django, gran parte di quella stessa filosofia vale (note che mostra “estensibilità” da nessuna parte nei nostri obiettivi). Perché visualizzazioni personalizzate Django possono fare nulla, e perché possono essere facilmente integrati in visivamente l'interfaccia di amministrazione (come descritto nel paragrafo successivo), il built-in opportunità per personalizzare l'interfaccia di amministrazione sono un po 'limitata per progettazione.

Si dovrebbe tenere a mente che l'interfaccia di amministrazione è “solo un app,” anche se molto complicato. E non fa niente che ogni sviluppatore Django con il tempo sufficiente non poteva riprodursi. E 'del tutto possibile che in futuro qualcuno svilupperà un'interfaccia di amministrazione diversa che si basa su un diverso insieme di ipotesi, e quindi si comporterà in modo diverso.

Infine, si deve sottolineare che, a partire da questa scrittura, gli sviluppatori Django stavano lavorando su una nuova versione del l'interfaccia di amministrazione che consente molta flessibilità più personalizzazione. Con il tempo di leggere questo, queste nuove funzionalità potrebbero hanno fatto la loro strada nella buona distribuzione di bona Django. Per scoprire, chiedere a qualcuno nella comunità Django se il ramo “nuove forme-admin” è stato integrato.

L'applicazione di amministrazione ha visto un sacco di miglioramento al fine di consentire una maggiore flessibilità nella personalizzazione, ma secondo me molto più di "Lo Zen di Admin" è ancora valido.