Вызов другого представления в пирамиде

Ага. Есть некоторые опасения

• не возвращает ответ
• предикаты/рендерер
• разрешения
• свойства запроса, связанные со старым запросом

Вот почему вы не должны вызывать представление из представления как функцию, если вы не знаете, что делаете.

Создатели пирамиды сделали отличный инструмент для перенаправления на стороне сервера - http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/subrequest.html

Вы можете вызвать представление с помощью request.invoke_subrequest:

from wsgiref.simple_server import make_server

from pyramid.config import Configurator

from pyramid.request import Request


def view_one(request):

    subreq = Request.blank('/view_two')
    response = request.invoke_subrequest(subreq)
    return response

def view_two(request):

    request.response.body = 'This came from view_two'
    return request.response

if __name__ == '__main__':

    config = Configurator()
    config.add_route('one', '/view_one')
    config.add_route('two', '/view_two')
    config.add_view(view_one, route_name='one')
    config.add_view(view_two, route_name='two')
    app = config.make_wsgi_app()
    server = make_server('0.0.0.0', 8080, app)
    server.serve_forever()`

Когда /view_one просматривается в браузере, текст, напечатанный в панели браузера, будет "Это пришло из view_two". Представление view_one использовало pyramid.request.Request.invoke_subrequest() API для получения ответа от другого представления (view_two) в том же приложении при его выполнении. Он сделал это, создав новый запрос с URL-адресом, который, как было известно, будет соответствовать регистрации представления view_two, и передал этот новый запрос pyramid.request.Request.invoke_subrequest(). Был вызван вызываемый объект представления view_two, и он вернул ответ. Затем вызываемый объект представления view_one просто возвращал ответ, полученный от вызываемого объекта представления view_two.

Я тоже боролся с этим. У меня есть решение, использующее метод render_to_response, хотя я уверен, что есть "более правильный" способ сделать это. Однако, пока кто-то не опубликует это, вот как я справился с этим:

from pyramid.renderers import render_to_response

@view_config(route_name="foo", renderer="foo.mak")
def foo_view(request):
    return {'stuff':'things', '_renderer':'foo.mak')

def bar_view(request):
    values = foo_view(request)
    renderer = values['_renderer']
    return render_to_response(renderer,values)

(Пирамида 1.3)

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

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

Документация по пирамиде здесь указывает, что оставление аргумента ключевого слова name вне view_config приведет к тому, что представление будет зарегистрировано самой функцией (а не строкой):

Такая регистрация... подразумевает, что имя представления будет *my_view*

Итак, в вашем случае вы должны иметь возможность использовать pyramid.view.render_view или pyramid.view.render_view_to_response напрямую, ссылаясь на foo_view:

@view_config(route_name="bar")
def bar_view(request):
    return pyramid.views.render_view_to_response(None, request, name=foo_view)

Обновление:

Да, вы правы, передача функции просмотра не работает.

Интересно, но взять код вашего примера и применить route_name к конфигу у меня не сработало. Однако в следующем примере просто присваивая представлению name, задается URL-адрес маршрута и присваивается имя представлению. В этом моде render_view_to_response работает так, как рекламируется. Назовите, ваши представления могут быть не такими, как вы хотите, но эта конфигурация выполняет то же самое, что и ваш пример кода, без дополнительной настройки.

@view_config(name="foo")
def foo_view(request):
    # returning a response here, in lieu of having
    # declared a renderer to delegate to...
    return Response('Where am i? `{0[whereami]}'.format({"whereami" : "foo!"}))

@view_config(name="bar")
def bar_view(request):
    # handles the response if bar_view has a renderer 
    return render_view_to_response(None, request, name='foo')

@view_config(name="baz")
def baz_view(request):
    # presumably this would not work if foo_view was
    # not returning a Response object directly, as it
    # skips over the rendering part. I think you would
    # have to declare a renderer on this view in that case.
    return foo_view(request)

if __name__ == '__main__':
    config = Configurator()
    config.scan()
    app = config.make_wsgi_app()
    serve(app, host='127.0.0.1', port='5000')

вы не можете сделать что-то вроде этого:

@view_config(name="baz") def baz_view(request): return HTTPFound(location=self.request.route_path('foo'))

Не точное решение, которое вы просили, а решение проблемы, которую вы описываете:

Создайте класс представления, в котором и foo, и bar являются методами. Тогда бар может вызвать self.foo()

К классу можно применить общую конфигурацию view_configuration, такую ​​как имя шаблона, а затем вы можете украсить каждый метод только именем представления.

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

@view_defaults(renderer="foo.jinja2")
class WhereaboutsAreFoo(object):

    @view_config(route-name="foo")
    def foo_view(self):
        return {"whereami" : "foo!"}

    @view_config(route-name="bar")
    def bar_view(self):
        return self.foo_view()