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

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

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

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

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

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

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

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

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

11.12.2008 03:50:02
6 ОТВЕТОВ

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

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

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

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

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

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

0
11.12.2008 04:09:50
Веб-сессии обычно НЕ являются уникальными для пользователя - у одного пользователя может быть несколько сессий одновременно, и веб-сервер обычно не знает, кто этот пользователь (веб-приложение обрабатывает это).
Rob Williams 24.12.2008 18:56:02
Пользователь не физическое существо здесь. Это абстрактная концепция, представленная специальным идентификатором, который каким-то образом хранится и передается во время общения. Технически «пользователь» может быть клонирован и использован несколькими приложениями одновременно, или одно приложение может иметь несколько.
Loki 26.12.2008 16:17:09

Это не проблема того, как управляются экземпляры. Поскольку 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. Если вам нужен больший контроль над удержанием, вы должны использовать локальные механизмы сохранения. Кеш сервера (любого типа), файловая система, база данных ... Тогда, конечно, вам нужно будет отфильтровать каждого пользователя вручную.

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

1
11.12.2008 07:12:22

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

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

1
11.12.2008 09:18:31

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

0
11.12.2008 09:41:01

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

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

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

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

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

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

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

  1. ПОЛУЧИТЬ ответ. Проверьте наличие cookie в шапке.

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

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

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

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

  2. ПОЧТОВЫЙ ответ. Проверьте наличие cookie в шапке.

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

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

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

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

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

3
11.12.2008 11:24:44

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

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

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

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

0
11.12.2008 18:02:19
Недостаточно информации, чтобы прокомментировать «плохую практику»
Rob Williams 24.12.2008 18:56:59