Держать переменную вокруг от поста, чтобы получить?

Question

У меня есть класс myClass, который определяет методы post () и get ().

Из index.html , у меня есть форма с действием, которая вызывает myClass.post (), которая извлекает некоторые данные из базы данных, устанавливает пару переменных и отправляет пользователя на new .html .

сейчас, new.html имеет форму, которая вызывает myClass.get ().

Я хочу, чтобы метод get () знал значение переменных, которые я получил в post (). Это главное здесь.

Я полагаю, что submit из new.html создает отдельный экземпляр myClass, созданный отправкой из index.html.

Есть ли способ как-нибудь получить доступ к "почтовому экземпляру"?

Есть ли обходной путь для этого? Если мне нужно, есть ли установленный способ отправить значение из post в "new.html" и отправить его обратно с get-submit?

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

Answer 1

То, о чем вы говорите, - это установление «сессии». То есть способ запомнить пользователя и состояние его транзакции.

Есть несколько способов решения этой проблемы, все из которых основаны на методах запоминания того, что вы во время сеанса.

HTTP не оказывает вам никакой помощи. Вы должны найти место для сохранения состояния сеанса на сервере и место для записи идентификатора сеанса на клиенте. Две большие техники:

• Используйте cookie для идентификации сеанса. Бесшовные и тихо.

• Используйте строку запроса в URL для идентификации сеанса. Очевидно, потому что у вас есть ?sessionid=SomeSessionGUID в ваших URL. Это разоблачает многое и делает закладки раздражающими. После очистки сеанса этот идентификатор сеанса все еще остается в закладках пользователей.

• Ограниченным образом вы также можете использовать скрытые поля в форме. Это работает, только если у вас есть формы на каждой странице. Не всегда верно.

Вот как это работает на практике.

1. GET response. Проверьте наличие cookie в шапке.

   а. Нет печенья. Первый раз пользователь. Создать сеанс. Сохраните его где-нибудь (память, файл, база данных). Поместите уникальный идентификатор в файл cookie. Отвечайте, зная, что это их первый раз.

   б. Cookie. Был здесь недавно. Попробуйте получить печенье.

   • НАЙТИ объект сеанса. Ответьте, используя информацию в куки.

   • убирайся. Нет сессии. Старое печенье. Создайте новый и ведите себя так, будто это их первый визит.

2. POST-ответ. Проверьте наличие cookie в шапке.

   а. Нет печенья. WTF? Глупые дети. Убирайся с моего газона! Кто-то добавил в закладки сообщение POST или пытается связываться с вашей головой. Ответьте, как будто это был первый раз GET.

   б. Cookie. Отлично. Получить печенье.

   • Найти объект сеанса. Найдите нужную вещь в объекте сеанса. Ответить.

   • убирайся. Нет сессии. Старое печенье. Создайте новый и ответьте так, как если бы вы впервые получили GET.

Вы можете сделать то же самое со строкой запроса вместо куки. Или скрытое поле в форме.

Answer 2

HTTP не имеет состояния, поэтому у вас нет (встроенного) способа узнать, является ли пользователь, загружающий одну страницу, тем же пользователем, который загрузил другую. Кроме того, даже если вы знаете, что, например, благодаря сессионным cookie-файлам, вы не можете сказать, является ли окно браузера, в которое они загружают следующую страницу, тем же, в котором они загрузили предыдущую страницу. несколько вкладок, обращающихся к вашему сайту, и вы не хотите, чтобы изменение состояния одной страницы перекрывало состояние другой.

Учитывая это, лучше всего включить параметры запроса в ссылку на страницу, извлекаемую с помощью GET, кодируя переменные, которые вы хотите отправить на страницу 'get' (убедитесь, что они не чувствительны, поскольку пользователь может изменять их!). Затем вы можете получить к ним доступ через self.request.GET в запросе get.

Answer 3

Это не проблема того, как управляются экземпляры. Поскольку HTTP не имеет состояния, ваша программа также фактически не имеет состояния. (Для длительных процессов, таких как GAE, это можно сделать иначе, но я не уверен, что вам понадобится эта сложность здесь)

Вы не предоставили никакого кода, но я предполагаю, что вы получаете POST, а затем вы перенаправляете к результатам (что является GET). Поэтому должно быть легко сохранить параметр:

def save_foo(request):
    if request.method == 'POST':
        save(request.POST)
        return HttpRedirect(reverse(
            'Some_Target',
            {'bar': 'baz', 'foo': request.POST['foo']}))
    else:
        # do something else

Это представление в случае POST заставляет клиента отправлять запрос GET на любой URL-адрес с псевдонимом Some_Target. И этот GET будет включать foo параметр из POST.

Это решение для одного просмотра. Если вам нужно такое поведение проекта, вы можете использовать промежуточное программное обеспечение для него. И на этот раз имеет смысл кэширование переменной.

Есть две вещи, которые делают меня немного неудобным при таком подходе:

1. Смешивание параметров GET и POST. Параметры GET должны использоваться для инструкций без побочных эффектов, таких как фильтрация. Параметр POST следует использовать для проверок с побочными эффектами, то есть для изменения данных. ИМХО следует избегать перемещения параметра из POST для получения.
2. Если нам требуется постоянство, использование экземпляров объектов (или областей действия функций, как в моем примере), как правило, не очень хорошая идея.
   1. Если это не конфиденциальная информация с более низкой потребностью в хранении, cookies - это путь. Они являются механизмом постоянства на стороне клиента, поэтому вы можете просто получить их из запроса и, если вы не измените их, они сохраняются (до истечения срока действия.)
   2. Если вам нужен больший контроль над удержанием, вам следует использовать локальные механизмы сохранения. Кэш сервера (любого типа), файловая система, база данных ... Тогда, конечно, вам нужно будет отфильтровать каждого пользователя вручную.

В любом случае я бы избегал кэширования в экземплярах.

Answer 4

ОК - Спасибо всем.

Я скоро опробую некоторые из этих идей и вернусь ко всем вам.

Кажется, я могу обойти некоторые из этих вещей, много писать и читать из хранилища данных *, но я подумал, что может быть более простой способ сохранить этот экземпляр класса (я пытаюсь использовать известные методы в веб-фреймворке, которые я еще не получил полностью).

* Например, создание уникальной записи на основе данных в POST и добавление некоторых переменных в тег. Это плохая практика?

Answer 5

Почему бы просто не использовать memcache для временного хранения переменной, а затем перенаправить на POST URL? Это кажется самым простым решением.

Answer 6

Я не знаю конкретно о движке приложений Google, но обычно вот что происходит:

На сервере будет какой-то пул потоков. Каждый раз, когда http-запрос отправляется на сервер, поток выбирается из пула или создается.

В этом потоке будет создан экземпляр какого-либо объекта контроллера. Этот объект решает, что делать с запросом (например, создание экземпляров других классов и предварительная обработка параметров запроса http). Обычно этот объект является ядром веб-фреймворков. Параметры запроса также повторно отправляются браузером каждый раз (сервер не может угадать, чего хочет браузер).

Веб-серверы обычно имеют хранилища состояний для объектов в постоянном или сеансовом состоянии. Сеанс представлен уникальным пользователем (обычно cookie или GUID в URL), срок действия которого истекает через определенное время.

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

Другим решением было бы отправить элементы обратно на страницу в виде параметров url в сгенерированном HTML-коде из первой функции, а затем вернуть их «как обычно» из второй функции.