промежуточное ПО и контекстный процессор для навигации/отображения, зависящего от вида

Это очень похоже на этот вопрос SO в промежуточном программном обеспечении и обмене представлениями

Мы хотели бы, чтобы наши шаблоны имели стандартный набор переменных контекста. Таким образом, процессор контекста кажется подходящим, однако не похоже, что процессор контекста осведомлен о представлениях. Раньше нам приходилось проверять стек вызовов, чтобы получить контекстную информацию о том, какое представление что делает.

Здесь мы увидели поток промежуточного программного обеспечения, а также сигнатуру process_view() для промежуточного программного обеспечения, которая дает нам дескриптор представления.

Это казалось более подходящим для наших нужд, но не позволяло нам изменять переменную контекста, как и другие методы промежуточного программного обеспечения.

Таким образом, наша первоначальная идея заключалась в том, чтобы изменить объект запроса со всей глобальной и контекстуальной информацией, необходимой для наших шаблонов, и заставить шаблоны вызывать из {{request.something}} для получения конкретной информации, которая нам нужна, например {{request.viewname}}.

Итак, наши вопросы:

  • Является ли изменение/установка значений в объекте запроса приемлемым для отправки контекстной/глобальной информации о приложении в ваши шаблоны? Или стандартная практика всегда помещать это в контекст?
  • Существуют ли способы/трюки, чтобы заставить контекстные процессоры знать, что они не включают его явную передачу или выполнение некоторой самоанализа стека?
  • Есть ли у middleware.process_response возможность изменять контекст или он неизменен?

django
person dmyung    schedule 14.08.2009    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Совершенно верно устанавливать переменные в запросе в промежуточном программном обеспечении - я делаю это все время.

Для этого нельзя использовать process_response, так как к тому времени шаблон уже отрендерен — на данный момент все, что вы получаете, — это HttpResponse, содержащий кучу HTML.

Альтернативой может быть обертка render_to_response вашей собственной функцией, которая берет контекст вместе с запросом и шаблоном и при необходимости изменяет его перед передачей фактической функции рендеринга. Преимущество этого заключается в изменении фактического контекста, но недостатком является то, что вы должны помнить, что нужно вызывать его в каждом представлении вместо функции по умолчанию.

person Daniel Roseman    schedule 14.08.2009

arrow_upward
2
arrow_downward

Вы можете сделать это, используя промежуточное ПО и контекстный процессор в тандеме. Промежуточное ПО знает о представлении и может установить атрибут в запросе. Затем процессор контекста может переместить в контекст все, что задано в запросе.

Например:

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

Затем контекстный процессор:

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