middleware vs. processore contesto per vista dipendente navigazione/visualizzazione

Question

Questa è una domanda molto simile a questo SO infilare su middleware and views communicating

Vorremmo avere i nostri modelli di essere dato un insieme standard di variabili di contesto. Quindi, un processore di contesto sembra appropriato, tuttavia, non sembra che il processore di contesto sia consapevole della vista. In precedenza eravamo stati costretti a ispezionare lo stack delle chiamate per ottenere informazioni contestuali su quale vista stava facendo cosa.

Ecco dove abbiamo visto il thread del middleware e la firma process_view() per un middleware che ci fornisce un handle per la visualizzazione.

Questo sembrava più vicino ai nostri bisogni, ma non ci ha permesso di modificare la variabile di contesto, né gli altri metodi di middleware.

Quindi la nostra idea intial sbandierati era quello di modificare l'oggetto richiesta, tutte le informazioni a livello mondiale e contestuali avevamo bisogno per i nostri modelli e costringere i modelli per chiamare dalla {{request.something}} per le informazioni specifiche cui abbiamo bisogno, come ad esempio {{request.viewname}}.

Quindi, le nostre domande:

• sta modificando/valori di impostazione sulla richiesta obiettare una cosa accettata da fare per spingere informazioni specifiche app contestuali/globale per i tuoi modelli? Oppure la pratica standard è sempre quella di metterlo in contesti?
• Esistono modi/trucchi per rendere consapevoli i processori di contesto che non comportano il passaggio esplicito o l'introspezione dello stack?
• Il middleware.process_response ha l'opportunità di modificare il contesto o è immutabile?

Answer 1

È perfettamente valido impostare le variabili sulla richiesta nel middleware: lo faccio sempre.

Per questo motivo non è possibile utilizzare process_response, poiché a questo punto il modello è già stato sottoposto a rendering: a questo punto tutto ciò che si ottiene è uno HttpResponse contenente un mucchio di codice HTML.

Un'alternativa potrebbe essere quella di avvolgere render_to_response con la propria funzione, che prende il contesto, insieme alla richiesta e al modello, e lo modifica se necessario prima di passare alla funzione di rendering effettiva. Questo ha il vantaggio di modificare il contesto reale, ma lo svantaggio è che devi ricordarti di chiamarlo in ogni vista invece della funzione predefinita.

Answer 2

È possibile farlo utilizzando il middleware e un processore di contesto in tandem. Il middleware conosce la vista e può impostare un attributo sulla richiesta. Quindi il processore di contesto può spostare qualsiasi cosa impostata nella richiesta nel contesto.

Ad esempio:

class ExtraContextMiddleware(object): 
    """ 
    Adds extra context to the response for certain views. 

    Works in tandem with the extra_context context processor. 
    """ 

    context_map = { 
     #Adds the supplied context dict to the named views 
     'my_view_name': {'foo': 'Hello', 'bar': 'Goodbye'}, 
    } 

    def process_view(self, request, view, *args, **kwargs): 
     try: 
      request.extra_context = self.context_map[view.func_name] 
     except KeyError: 
      pass 

Poi il processore contesto:

def extra_context(request): 
    """Context processor for adding extra context. 
    Works in tandem with ExtraContextMiddleware.""" 
    try: 
     return request.extra_context 
    except AttributeError: 
     return {}