Возврат на предыдущую страницу

[BuHunyx]

Доброе время суток. У формы установлено action="action.php" , что нужно прописать в action.php что бы после того как всё отработало выдыть сообщение и вернуться на предыдущую страницу(т.е. на форму с которой вызывалось action.php ) , и как проверять строку на пустое значение.

[s0rr0w]

Доброе время суток. У формы установлено action="action.php" , что нужно прописать в action.php что бы после того как всё отработало выдыть сообщение и вернуться на предыдущую страницу(т.е. на форму с которой вызывалось action.php ) , и как проверять строку на пустое значение.

Копать в сторону функции header

[gesandte]

используй empty для проверки на пустое значение

[rus]

<a href="java script:history.back()">Вернуться назад</a>

[s0rr0w]

<a href="java script:history.back()">Вернуться назад</a>

= запостить форму еще раз... и еще раз... и снова...

[3d_max_9]

Доброе время суток. У формы установлено action="action.php" , что нужно прописать в action.php что бы после того как всё отработало выдыть сообщение и вернуться на предыдущую страницу(т.е. на форму с которой вызывалось action.php ) , и как проверять строку на пустое значение.

Можно еще попробовать с массива $_SERVER вытянуть:

$url = $_SERVER['HTTP_REFERER'];

[Flare]

Доброе время суток. У формы установлено action="action.php" , что нужно прописать в action.php что бы после того как всё отработало выдыть сообщение и вернуться на предыдущую страницу(т.е. на форму с которой вызывалось action.php ) , и как проверять строку на пустое значение.

Есть еще решение:

не указывать action. Тогда данные формы будут обрабатываться тем же скриптом, который эту форму выдаёт.

Напишите обработчик формы перед её выдачей и проверяйте, если форма сработала, то выдавайте сообщение которое хотели выдавать с помощью action.php. А затем выдавайте и саму форму.

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

[rus]

Есть еще решение:

не указывать action. Тогда данные формы будут обрабатываться тем же скриптом, который эту форму выдаёт.

Напишите обработчик формы перед её выдачей и проверяйте, если форма сработала, то выдавайте сообщение которое хотели выдавать с помощью action.php. А затем выдавайте и саму форму.

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

Ага, и разрешить тем самым просматривать пользователю какие переменные передаются гетом из формы

А если она в бд делает запись?

= запостить форму еще раз... и еще раз... и снова...

То есть ты имеешь ввиду то что при возврате назад данные в форме сохраняются?

Если это, то тогда лучше наверное так как сказал 3d_max_9

[Flare]

Ага, и разрешить тем самым просматривать пользователю какие переменные передаются гетом из формы

А если она в бд делает запись?

Так передавай параметры методом post

И потом, не пойму, в чём собственно проблема?

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

Смотришь исходный код формы, собираешь переменные и вперёд

Как раз обработчик этих переменных и должен брать весь удар на себя.

Метод post в этом случае даже надёжнее будет. Когда php обработает все входные данные с формы, никто не увидит что он передаст в бд дальше.

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

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

[rus]

И потом, не пойму, в чём собственно проблема?

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

Проблем абсолютно никаких, тем более у меня.

А вот исходный код пыхи вы ну никак не узнаете, так как он выполняется на сервере, да и защищен от просмотра.

[Flare]

rus, вы абсолютно правы.

Я же пишу:

Как раз обработчик этих переменных и должен брать весь удар на себя.

Только не пойму почему вы говорите про метод get? Его вообще нужно использовать в редких случаях, когда post не уместен. Ведь основная задача программиста в работе с формами — побольше скрыть от посторонних глаз.

[rus]

rus, вы абсолютно правы.

Я же пишу:

Только не пойму почему вы говорите про метод get? Его вообще нужно использовать в редких случаях, когда post не уместен. Ведь основная задача программиста в работе с формами — побольше скрыть от посторонних глаз.

Есть еще решение:

не указывать action. Тогда данные формы будут обрабатываться тем же скриптом, который эту форму выдаёт.

По умолчанию, если не указать экшен у формы и метод, то метод будет ГЕТ, а если он явно указан и указан адрес (путь до обработчика), то будет ПОСТ.

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

Edited October 1, 2009 by rus

[Flare]

По умолчанию, если не указать экшен у формы и метод, то метод будет ГЕТ, а если он явно указан и указан адрес (путь до обработчика), то будет ПОСТ.

Может вы что-то путаете?

action и method это разные параметры формы и отвечают они за разные вещи.

Значения по умолчанию, это дело одно. Но когда программируешь серьёзные вещи, все умолчания не в счёт. Method нужно прописывать всегда, даже если он get. С action уже разобрались.

rus, какие могут быть «по умолчанию»? Вы же не оставляете margin и padding по умолчанию при вёрстке.

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

[s0rr0w]

Может вы что-то путаете?

action и method это разные параметры формы и отвечают они за разные вещи.

Значения по умолчанию, это дело одно. Но когда программируешь серьёзные вещи, все умолчания не в счёт. Method нужно прописывать всегда, даже если он get. С action уже разобрались.

rus, какие могут быть «по умолчанию»? Вы же не оставляете margin и padding по умолчанию при вёрстке.

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

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

[rus]

Может вы что-то путаете?

action и method это разные параметры формы и отвечают они за разные вещи.

Значения по умолчанию, это дело одно. Но когда программируешь серьёзные вещи, все умолчания не в счёт. Method нужно прописывать всегда, даже если он get. С action уже разобрались.

rus, какие могут быть «по умолчанию»? Вы же не оставляете margin и padding по умолчанию при вёрстке.

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

Читаем внимательно!

Массивы $HTTP_GET_VARS и $HTTP_POST_VARS

Для доступа к данным формы, переданной через метод GET или POST, используются специальные массивы, соответственно, $HTTP_GET_VARS и $HTTP_POST_VARS. Например, имя поля формы, заданное параметром name, называется lorana, тогда для получения значения этого поля используется запись $HTTP_GET_VARS["lorana"]. Это будет в том случае, если параметр method тега <FORM> равен значению get или вообще отсутствует, поскольку по умолчанию значение атрибута method равно get. Аналогично обстоит дело и с методом POST.

Уже на слово и не верят.

[Flare]

rus, толи мы с вами на разных языках говорим, толи о разных вещах…

Зачем вы мне рассказываете про $HTTP_GET_VARS и $HTTP_POST_VARS, если мы обсуждаем action?

Ещё раз говорю, наличие значений по умолчанию — это хорошо, но action и method прописывать нужно всегда.

Выбор метода — личное дело программиста, мотивированное поставленной перед ним задачей.

А action — это просто путь до скрипта-обработчика данной формы.

Для доступа к данным формы, переданной через метод GET или POST, используются специальные массивы, соответственно, $HTTP_GET_VARS и $HTTP_POST_VARS. Например, имя поля формы, заданное параметром name, называется lorana, тогда для получения значения этого поля используется запись $HTTP_GET_VARS["lorana"]. Это будет в том случае, если параметр method тега <FORM> равен значению get или вообще отсутствует, поскольку по умолчанию значение атрибута method равно get. Аналогично обстоит дело и с методом POST.

Спасибо, конечно, за ликбез, но я это уже давно знаю.

Я 5 лет на php программирую, из них 4 года пишу движки для сайтов (на заказ)

[rus]

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

Да, можно методом ПОСТ например, вы какой-то другой метод имели ввиду?

rus, толи мы с вами на разных языках говорим, толи о разных вещах…

Зачем вы мне рассказываете про $HTTP_GET_VARS и $HTTP_POST_VARS, если мы обсуждаем action?

Я сказал, что если не указывать путь (action="") до обработчика и не указывать метод (method="POST", "GET") обработки формы, то по умолчанию, форма будет обрабатываться методом GET, при этом естесственно скрипт обработчика должен находиться на одной странице с формой.

Спасибо, конечно, за ликбез, но я это уже давно знаю.

Я 5 лет на php программирую, из них 4 года пишу движки для сайтов (на заказ)

Не за что! Обращайтесь если что

O_o я вас поздравляю

[gesandte]

Читаем внимательно!

Для доступа к данным формы, переданной через метод GET или POST, используются специальные массивы, соответственно, $HTTP_GET_VARS и $HTTP_POST_VARS. Например, имя поля формы, заданное параметром name, называется lorana, тогда для получения значения этого поля используется запись $HTTP_GET_VARS["lorana"]. Это будет в том случае, если параметр method тега <FORM> равен значению get или вообще отсутствует, поскольку по умолчанию значение атрибута method равно get. Аналогично обстоит дело и с методом POST.

Уже на слово и не верят.

Вроде как щас все используют массивы $_GET и $_POST, а то что написано выше, это прошлый век

Edited October 1, 2009 by gesandte

[Flare]

Вроде как щас все используют массивы $_GET и $_POST, а то что написано выше, это прошлый век

Так и есть

[rus]

Вроде как щас все используют массивы $_GET и $_POST, а то что написано выше, это прошлый век

А какие используют массивы для передачи данных из формы?

[gesandte]

rus, читай:

Переменные, определенные для загруженных файлов, зависят от версии PHP и текущей конфигурации. Суперглобальный массив $_FILES доступен начиная с PHP 4.1.0. Массив $HTTP_POST_FILES доступен начиная с PHP 4.0.0. Эти массивы содержат всю информацию о загруженных файлах. Использование $_FILES является более предпочтительным. В случае, если конфигурационная директива register_globals установлена значением on, дополнительно будут объявлены переменные с соответствующими именами. Начиная с версии 4.2.0 значением по умолчанию для опции register_globals является off.

Содержимое массива $_FILES для нашего примера приведено ниже. Обратите внимание, что здесь предполагается использование имени userfile для поля выбора файла, как и в приведенном выше примере. На самом деле имя поля может быть любым.

$_FILES['userfile']['name']

Оригинальное имя файла на компьютере клиента.

$_FILES['userfile']['type']

Mime-тип файла, в случае, если браузер предоставил такую информацию. Пример: "image/gif".

$_FILES['userfile']['size']

Размер в байтах принятого файла.

$_FILES['userfile']['tmp_name']

Временное имя, с которым принятый файл был сохранен на сервере.

$_FILES['userfile']['error']

Код ошибки, которая может возникнуть при загрузке файла. Ключ ['error'] был добавлен в PHP 4.2.0

Замечание: В PHP 4.1.0 и более ранних версиях описанный выше массив назывался $HTTP_POST_FILES и не являлся суперглобальным, в отличие от $_FILES. В PHP 3 массив $HTTP_POST_FILES не определен.

[rus]

Согласен, я немного неправильно написал, поправлюсь:

Речь шла не о массивах, а о методах, а вы про массивы.

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

[3d_max_9]

Если это, то тогда лучше наверное так как сказал 3d_max_9

А чем собственно этот метод плох?

[rus]

А чем собственно этот метод плох?

Этот - это какой?

[gesandte]

Согласен, я немного неправильно написал, поправлюсь:

Речь шла не о массивах, а о методах, а вы про массивы.

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

Согласен, метода 2 =)

[3d_max_9]

Этот - это какой?

$url = $_SERVER['HTTP_REFERER'];