SSI+PHP

← →
KSergey © (2009-09-11 11:21) [0]

Сорри, что пишу здесь.

Хочу организовать такую штуку:
SSI-оболочка, имеющая такую структуру

add.shtml:   

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

← →
KSergey © (2009-09-11 13:24) [1]

Хорошо, конкретизирую вопрос.

Сервер апач.
Возьмем простейший html-файл с формой, где указан метод POST, а на кнопке submit стоит в action тот же html-файл.
Беза вот в чем: при нажатии на кнопку выдается ошибка:

Method Not Allowed
The requested method POST is not allowed for the URL /a.html.

Я так понимаю, где-то есть явный запрет на обращение методом POST к html-файлам. Но где? Как его убрать?

Курил настройка апача, но пока не удалось придумать такие, чтобы ошибка ушла.

Может кто подскажет?

← →
McSimm © (2009-09-11 13:33) [2]

А что должен делать апач с POST запросом для html файла ?
(Вопрос риторический)

Вы пост должны делать на /cgi-bin/qa/add.php
А в самом add.php после обработки можно сделать header(/a.html)

← →
McSimm © (2009-09-11 13:36) [3]

header("Location: ...") имел в виду

← →
Дмитрий С © (2009-09-11 13:39) [4]

> KSergey © (11.09.09 13:24) [1]

А в логе что?

> McSimm © (11.09.09 13:33) [2]

А я обычно делаю так:
add.php:
<?
ob_start();
... какая то обработка
$contents = ob_get_contents();
ob_end_clean();
include("add.shtml");
?>

add.shtml:
<html>
.....
<body><?=$contents?></body>
</html>

сорри за оффтоп

← →
KSergey © (2009-09-11 13:43) [5]

> McSimm © (11.09.09 13:33) [2]
> А что должен делать апач с POST запросом для html файла ? (Вопрос риторический)

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

Впрочем, ответ у меня на него есть: ничего. Да, просто ничего. Меян это устроит. (Хотя, конечно, я очень надеюсь, что он мне будет доступен внутри скрипта, вызванного из SSI.)

> Вы пост должны делать на /cgi-bin/qa/add.php
> А в самом add.php после обработки можно сделать header(/a.html)

Я наконец-то нашел причину, по которой иначе и невозможно сделать: add.php формирует иногда HTTP-заголовки, что, понятно, будет ему недоступно в составе SSI.
Окей, вопрос с html в action. Отпадает.

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

Инак, нарисовали форму обычным даже HTML. в action списали php-скрипт. Скрипт проверил -
1) если данные ok - то проблем нет, редиректнул на другую страницу, со списком того, что добавлялось. Эта ветк проблем не вызывает.
2) если не ok - то хочется показать ту же форму, с заполенными данными и текстом ошибки. Вот тут беда: если редиректнуть на ту же html-форму - то как в нее запихать уже введенные данные? если форму будет формировать все же SSI-конструкция, в которой будет кусок скрипта (не тот, которй add) - то опять вопрос как в него пропихнуть то, что уже введено? Какие есть механизмы? Или может совершенно волшебным образом ему будут доступны значеня, ранее POST переданные в add.php?

← →
McSimm © (2009-09-11 13:44) [6]

> Дмитрий С © (11.09.09 13:39) [4]
> А я обычно делаю так:

Использование редиректа после POST имеет свои плюсы.

> include("add.shtml");

Здесь совсем не тот случай. shtml апачем обрабатывается особо. Если сделать так - инклудом, то браузер просто получит SSI инструкции в исходном виде

Тут сразу попутно сомнение - а нужен ли SSI вообще... но это в принципе не мое дело :)

← →
KSergey © (2009-09-11 13:44) [7]

> Дмитрий С © (11.09.09 13:39) [4]
> А в логе что?

Ошибка 405 при обращении. Все :(
errorlog пуст :(

← →
KSergey © (2009-09-11 13:47) [8]

> McSimm © (11.09.09 13:44) [6]
> Тут сразу попутно сомнение - а нужен ли SSI вообще... но это в принципе не мое дело :)

Скажем так: я прекрасно понимаю, что все это можно отлично сделать на php скрипте.
Но хочется вот реализовать именно указанную мною конструкцию. Другое дело, что если это невозможно - тогда от этого откажусь. НО надежда пока есть :)

← →
McSimm © (2009-09-11 13:53) [9]

> Хотя, конечно, я очень надеюсь, что он мне будет доступен
> внутри скрипта, вызванного из SSI.

Это ошибка. На каждый SSI команду апач формирует собственный отдельный GET запрос и именно его (запроса) данные вы получите в скрипте. Разумеется данных POST там быть не может и не должно - они относятся к исходному запросу

> Тогда вопрос как это все организовать?

Я бы вообще отказался от SSI. PHP умеет делать include неплохо :)
Вопрос с валидацией данных имеет свои тонкости.
Один подход - валидировать на клиенте с помощью скрипта - тогда схема на сервере не меняется.
Вот если так по каким-то причинам не хочется или нельзя - тогда есть разные подходы и у всех есть недостатки.
Некоторые используют сессии, в которых хранят ошибку и данные. Некоторые в случае невалидных данных возвращают форму вместе с данными прямо в ответе от POST запроса, без редиректа

← →
McSimm © (2009-09-11 13:54) [10]

> Но хочется вот реализовать именно указанную мною конструкцию.
>

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

← →
McSimm © (2009-09-11 13:56) [11]

>
> Сессии тут сработают.

Похоже я поторопился. не сработают

Остается проверять ввод на клиенте с помощью JS. Я другого не вижу

Занимался я этим. Неудобная и устаревшая штука. Пришлось отказаться.
Здесь все подробно описано: http://www.ssi-developer.net/htaccess/

Я понял, всем большое спасибо.

Понятно, что сильно динамичные сайты лучше делать иначе, но тут-то почти статика, думал проскочить в том же ключе, что и весь сайт сделан. Ну раз нет - то значит нет.

> McSimm © (11.09.09 13:53) [9]
> Я бы вообще отказался от SSI. PHP умеет делать include неплохо :)

Все было бы совсем волшебно, если бы еще header и footer не содержали внутри себя в свою очередь SSI-директивы :) Но все решаемо, понятно.

← →
Канадец (2009-09-11 22:02) [15]

> 2) если не ok - то хочется показать ту же форму, с заполенными
> данными и текстом ошибки.

Чем не устраивает AJAX? А лучше всего комбинированный подход. Что можно
проверяет JS, что нельзя через AJAX на сервер и назад. Как результат страница не перегружается, все введенные данные на месте. Или я что-то недопонял?

> Канадец (11.09.09 22:02) [15]
>Чем не устраивает AJAX?

Ага, мне только аджаксу до кучи не хватает на простейшую страничку :)

Попался замечательный метод в PHP для apache, зовется virtual.
Этот тот же include, но прогоняет включаемые файлы четез SSI-транслятор. Ну конкретно мне сильно помогло, чтоыб все не перелопачивать и попроще вписаться в имеющуюся структуру организации страничек.

Еще вот интересно: PHP на много тяжелее SSI, например? ну вот если один и тот же функционал запользовать, например?

SSI+PHP Найти похожие ветки