Re: [apache-talk] ????? ?????? ? POST

["Khimenko Victor" <khim@xxxxxxxxxxxx>]

In <14055.61116.977674.606065@xxxxxxxxxxxx> Artem Chuprina (ran@xxxxxxxxx) wrote:
>>>>>> On Thu, 11 Mar 1999 18:55:33 +0300 (MSK), "Khimenko Victor" <khim@xxxxxxxxxxxx> said:

 AC>> во-вторых, что более серьезно, меня совершенно не устраивает его
 AC>> функциональность, и потому я им не пользуюсь.

 KV>> Гм. А что в нем так уж криво ?

AC> Генерация html.  В <select>, когда надо отсортировать по labels, что
AC> требуется на порядок чаще, чем наоборот, правильный порядок сортировки
AC> можно получить только из запроса к базе с order by и почленным
AC> заполнением массива values.  А попробуй правильно отсортировать только
AC> средствами перла!

А зачем ВООБЩЕ это делать ? Я обычно задаю просто список полей в соответсвующем
скрипте в том порядке в котором я этого хочу В ФОРМЕ. А уж в какой
последовательности в базе хранятся -- не мое дело.

AC> А если обрабатываются ошибки и хочется вывести все,
AC> что удалось до ошибки собрать, то все равно лучше собирать руками --
AC> тогда где-то перед началом eval достаточно объявить один скаляр вместо
AC> массива и хеша.  Да и памяти на сбор select'а сразу в строку требуется
AC> где-то втрое меньше.  Тег <tr> мы почему-то умеем только целиком, по
AC> частям (отдельно <tr>, отдельно </tr>) нам почему-то недоступно.  Хотя
AC> покажите мне ситуацию, когда удобно выдать сразу всю строку таблицы.
AC> Вот и получается: когда пишешь $q->tag(), когда просто "<tag>".  А потом
AC> черт ногу сломит в этом скрипте...

Не знаю. Я оттуда такие tag'и не использовал. Только вещи, которые могут
меняться (<input, <textarea, etc)...

 AC>> Поднимать его ради разбора multipart/form-data, если он ее
 AC>> умеет -- нафиг, нафиг.

 KV>> Мы лучше свой велосипед построим ! "Национальная гордость великороссов" ?

AC> Как тебе сказать...  HTML мы генерим хреново и неудобно для
AC> программиста.

Мне было достаточно.

AC> Функциональность GET и всяких редиректов модуль Apache
AC> нам перекрывает с головой.

Пожалуй... Если его можно применить :-))

AC> Немножко уступает в обычном POST (не разбирает сразу на параметры) и
AC> не реализован multipart/form-data.  Вот тебе и велосипед.

AC> Apache мы все равно use, авторизации и информации о
AC> конфигурации ради, и покажите мне теперь смысл забивать память модулем
AC> CGI.

Ради POST и miltipart/form-data :-)) Снявши голову по волосам не плачут:
по сравнению с ресурсами потребными проста на запуск интерпретатора perl'а
ресурсы на обработку CGI.pm попросту меркнут...

 VBW>> Вообще, написать код, который понимает все три вида концов строк -
 VBW>> несложно,

 AC>> Но длинно.

 KV>> RFC1867 ссылается на MIME, где все строки должны кончаться на CRLF. Соблюдают
 KV>> ли все browser'ы это требование -- бог весть... То, что MS IE стандарты не
 KV>> соблюдает (и посылает-таки \n -- сам на это нарывался :-) -- это уже как бы
 KV>> добрая традиция, а вот есть ли кто-нибудь еще -- не знаю...

AC> Ну что ж, this site does not support M$ IE.  And never will.  Ссылка на
AC> стандарт у меня теперь есть, остальное проблемы юзеров.

К сожалению M$ IE таки самый популярный browser :-)) И чем дальше в лес, тем
будет более популярен за счет Windows98/2000 (в ближайшие лет несколько,
конечно)...

 KV>> Он и не обязан :-) Зато ты обязан склеивать строки, разбираться с commenets
 KV>> и quoted-strings (RFC2045, Appendix A; RFC822, 3.4.8, 3.4.3 и 3.4.5)...

AC> А кто при multipart/form-data режет заголовки и кодирует строки?

Не знаю. Но "право имеют".

 KV>> А есть еще ошибки Netscape'а (он неправ, забывая обрабатывать кавычки в
 KV>> именах файлов, но жаловаться-то будут тебе :-)

AC> А что, CGI это обрабатывает?

Угу.

AC> С нетшкафом довольно просто -- filename=
AC> имеет тенденцию заканчивать строку, так что соответствующий регексп
AC> выглядит

AC> \bfilename="(.+)"\s*$

Ну это когда как :-)) Стандарт этого не требует...

 KV>>  и MS IE (MS IE для Mac'а
 KV>> забывает добавлять "--" к boundary :-)

AC> В начало или в конец?  Впрочем, маков у нас внутри нет.

В начало.

 KV>> В общем изобретение велосипеда -- вещь похвальная, но хлопотная...

AC> Может, ты и уговорил завести на это CGI...  Но вообще, мрачный модуль.
AC> Я лучше попробую выкусить из него нужную функцию.

Попробуй...



=============================================================================
=               Apache-Talk@xxxxxxxxxxxxx mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =