Отказаться от метода Post вообще

[DragonMX]

Вот задумал переделать сайт полностью без POST. Не нравится он мне тем, что кнопка Назад потом криво работает. Все, что нужно отправить, хочу отправлять аяксом через JsHttpRequest, а потом делать автопереход через windows.location (или другой эквивалентный способ). Даже аутентификацию хочу сделать так же. Пока проблем не вижу - кнопка назад будет работать, отправка получит интерактивность, JsHttpRequest в отличие от POST позволяет отправлять просты объекты и сложные массивы на сервер. Я ничего не упустил? Не хочу потом топтаться по граблям.

[Veseloff]

Ну, во-первых, яваскрипт может быть и выключен и тогда отправка аяксом не будет работать вообще. А что касается кнопки "Назад" (впрочем как и обновления страницы), то после обработки данных формы делаем header("Location: страница_перехода"); и всё будет в порядке - я никогда не испытываю проблем с этим. Так что не стоит отказываться, ИМХО.

[s0rr0w]

А файлы как передавать?

[DragonMX]

Veseloff

яваскрипт может быть и выключен

Слушайте, реально чтоли до сих пор кто-то может отключать ява-скрипт? Мне кажется, такие времена уже прошли. Но даже если так, то включенный ява-скрипт будет скорее правилом этого сайта, иначе там ничего работать не будет. Дерево с динамической подгрузкой без аякса не сделаешь, а иначе там слишком много сразу грузить. Списки, которые составляются в зависимости от того, что было выбрано ранее. Есть обработка строк на ходу. Да и есть там одна часть сайта, которая идет с ява-скрипт по технологии, так сказать - про AICC если слышали. А раз ява-скрипт включен по требованию, то надо им пользоваться по-полной.

после обработки данных формы делаем header("Location: страница_перехода"); и всё будет в порядке

Да, я замечал, что это работает. А во всех браузерах? Знаю, что Опера по-своему обрабатывает Назад - такое ощущение, что она просто показывает предыдущую страницу, а не переходит на нее. Мало ли еще фокусов в разных браузерах.

s0rr0w

А файлы как передавать?

JsHttpRequest может файлы передавать. Сам еще не пробовал, но все понятно: так же создается input типа file и в request передается сам объект input - в этом случае содержимое придет на сервер в $_FILES.

[Veseloff]

1. А еще некоторые до сих пор могут использовать презервативы во время секса. Да, и еще используются зацементированные, так сказать, и смазанные эпоксидной смолой, если слышали.

2. Везде работает 100%

3. Ниссы, еще и флэш может передавать файлы. А, да, ЭктивИкс еще есть для убогих.

[DragonMX]

Veseloff

Отказаться от JS я не смогу. Как минимум, он используется при воспроизведении уроков по AICC - это у них в стандартном примере даже прописано. Даже если я откажусь от JS в одном месте, он останется в других, а значит нет смысла.

Кроме отключенного JS проблемы могут быть?

[Searcher]

Максимализм - плохая вещь в программировании. Надо подходить рационально. А не все переделывать, если возникло пару каких-то сложностей. Проблемы с post у вас из-за нехватки знаний, поскольку все программисты используют этот метод и не видят никаких проблем. Да, броузеры кэшируют страницы, но в заголовке для броузера можно передать инструкцию, чтобы он не кэшировал, и все будет нормально.

Любые усложнения в программе и надстройки увеличивают вероятность ошибок, глюков и т.п. Есть короткий и простой путь передачи информации - post. Зачем ехать в Ленинград через Европу, если есть путь короче?

JsHttpRequest хорошо использовать для передачи и получения данных для изменения отдельных элементов страницы без её перезагрузки. А если вам нужно вывести другую страницу после передачи данных, то использовать JsHttpRequest совершенно нерационально, тут проще и логичнее post.

[e1f]

JsHttpRequest может файлы передавать. Сам еще не пробовал, но все понятно: так же создается input типа file и в request передается сам объект input - в этом случае содержимое придет на сервер в $_FILES.

Это что за бред? Что куда прийдет? iframe там, батенька, iframe.

[s0rr0w]

Это что за бред? Что куда прийдет? iframe там, батенька, iframe.

Речь идет про библиотеку, и там действительно используется iframe.

JsHttpRequest хорошо использовать для передачи и получения данных для изменения отдельных элементов страницы без её перезагрузки. А если вам нужно вывести другую страницу после передачи данных, то использовать JsHttpRequest совершенно нерационально, тут проще и логичнее post.

Обоснуй, почему не рационально?

[e1f]

Да, видимо я был введен в заблуждение фразой

так же создается input типа file и в request передается сам объект input - в этом случае содержимое придет на сервер в $_FILES.

[Searcher]

Обоснуй, почему не рационально?

А смысл писать лишний код, тратить время, напрягать интерпретатор броузера дополнительным скриптом отправки-получения, потом наверняка еще добавится скрипт обработки полученных данных и изменения страницы, dom и т.п. на стороне броузера? Это все делается гораздо проще и только на стороне сервера. Бывают исключения, но в типичных случаях не рационально.

Edited October 12, 2009 by Searcher

[s0rr0w]

А смысл писать лишний код, тратить время, напрягать интерпретатор броузера дополнительным скриптом отправки-получения, потом наверняка еще добавится скрипт обработки полученных данных и изменения страницы, dom и т.п. на стороне броузера? Это все делается гораздо проще и только на стороне сервера. Бывают исключения, но в типичных случаях не рационально.

Лишний код?

Давай сравним две технологии генерации страницы данных.

Статическая страница

1. Запросить данные для меню.

2. Запросить данные всех модулей, которые отображаются на странице помимо контента

3. Запросить данные контента

4. Отобразить все это.

Динамическая подгрузка

1. Запросить данные для контента

2. Отобразить.

Скриптов там одинаково немного, если строить все правильно идеологически.

[Searcher]

Лишний код?

Давай сравним две технологии генерации страницы данных.

Статическая страница

1. Запросить данные для меню.

2. Запросить данные всех модулей, которые отображаются на странице помимо контента

3. Запросить данные контента

4. Отобразить все это.

Динамическая подгрузка

1. Запросить данные для контента

2. Отобразить.

Скриптов там одинаково немного, если строить все правильно идеологически.

А как насчет совместимости сайта с мобильными устройствами? Да и кроссбраузерность порой страдает. Если кэшируется все, то для статической страницы трафика не существенно будет больше, а на стороне клиента при динамической странице браузер неплохо загружается и скорость рендеринга снижается, все равно перерисовывать надо. Еще и скрипт реализации HttpRequest не мало весит и все-таки загружает интерпретатор.

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

[s0rr0w]

А как насчет совместимости сайта с мобильными устройствами? Да и кроссбраузерность порой страдает. Если кэшируется все, то для статической страницы трафика не существенно будет больше, а на стороне клиента при динамической странице браузер неплохо загружается и скорость рендеринга снижается, все равно перерисовывать надо. Еще и скрипт реализации HttpRequest не мало весит и все-таки загружает интерпретатор.

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

Ну а головой подумать?

Вот вам код

<div class="defContent">
 <a href="#" onclick="doRequest('news'); return false;">Новости</a>
</div>
<div class="forPortable">
 <a href="/news/">Новости</a>
</div>

.forPortable { display: none }
@media handheld {
 .defContent { display: none }
 .forPortable { display: block }
}

Таким образом можно разложить весь сайт на набор маленьких страниц с нормальными ссылками.

Маленькие кусочки можно тоже кешировать как и цельные страницы. Разницы - ноль.

Интерпретатор не нужен, если передавать готовый HTML.

По поводу форума. Переход на уже загруженные страницы не будет требовать запроса на сервер. Выгода очевидна.

[Searcher]

@media handheld - это пока не везде работает.

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

Интерпретатор все равно нужен, кто ж будет сам скрипт JsHttpRequest обрабатывать?

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

Пока не вижу выгоды.

[s0rr0w]

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

Усложнение там мизерное. Да и любую задачу можно решить разными способами.

А без этого поисковики будут плохо индексировать сайт.

Если создать прецендент, то поисковики изменят свое отношение к таким сайтам.

Больше работы, запутаться и напартачить больше вероятность.

Где там больше работы? Больше работы со страницей, на которой нужно показывать несколько модулей. Вот там точно можно запутаться.

Приведу простой пример.

Есть набор базовых функций, например

* получить меню

* получить список новостей

* получить список статей

* получить текст новости

* получить текст статьи

* получить календарь с указанием заполненности

Как видим, все можно свести к трем базовым типам: список(дерево), статья, календарь.

Пишем три базисные функции, которые принимают параметры, а в ответ генерируют HTML. В зависимости от темплейта или типа данных, генерируется разный код.

Итак, у нас есть три функции, один index.cgi, несколько темплейтов для разных типов данных. Что тут сложного?

Интерпретатор все равно нужен, кто ж будет сам скрипт JsHttpRequest обрабатывать?

Зачем? Я три раза написал, что можно спокойно HTML пересылать.

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

Пока не вижу выгоды.

Данные можно гонять в виде JS. Меньше по размерам, правда на генерацию чуть больше времени будет затрачено.

[Searcher]

Усложнение там мизерное. Да и любую задачу можно решить разными способами.

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

Если создать прецендент, то поисковики изменят свое отношение к таким сайтам.

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

Где там больше работы? Больше работы со страницей, на которой нужно показывать несколько модулей. Вот там точно можно запутаться.

Приведу простой пример.

Есть набор базовых функций, например

* получить меню

* получить список новостей

* получить список статей

* получить текст новости

* получить текст статьи

* получить календарь с указанием заполненности

Как видим, все можно свести к трем базовым типам: список(дерево), статья, календарь.

Пишем три базисные функции, которые принимают параметры, а в ответ генерируют HTML. В зависимости от темплейта или типа данных, генерируется разный код.

Итак, у нас есть три функции, один index.cgi, несколько темплейтов для разных типов данных. Что тут сложного?

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

Зачем? Я три раза написал, что можно спокойно HTML пересылать.

Ты не понял, HTML то можно присылать, но это же все-таки скрипт: onclick="doRequest('news'); return false;". Но это уж ладно, этим можно пренебречь.

Данные можно гонять в виде JS. Меньше по размерам, правда на генерацию чуть больше времени будет затрачено.

Можно, но опять таки больше программирования, больше времени и т.п. чем в стандартном способе...

Вобщем, двигаться в эту сторону наверно стоит, но постепенно. Использовать пока только в некоторых элементах, потом в некоторых страницах. Но на данный момент в большинстве случаев прекрасно работает старый метод post и не имеет никаких серьезных недостатков.

Как говорится: "Умный в гору не пойдет, умный гору обойдет".

Мне нравится твой взгляд, идеалистичный и оптимистичный, это и двигает прогресс. Но в реальности все не так просто получается...

[DragonMX]

Searcher

Есть короткий и простой путь передачи информации - post

Короткий, когда все вбито в соответствующие поля. У меня наравне с этим часто надо передавать вычисляемые данные. Не спорю, можно по onclick посчитать все нужное, засунуть в input type="hidden" и отправить post'ом, но все равно уже JS нужен. А если на сервер надо отправить массив или дерево? Может быть, я просто не знаю, как - как это отправить post'ом? Если только сериализацией, но надо писать сериализатор под JS.

потом наверняка еще добавится скрипт обработки полученных данных и изменения страницы, dom и т.п. на стороне броузера

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

А как насчет совместимости сайта с мобильными устройствами?

Да, здесь с JS напряг, но есть и целевая аудитория - у меня в нее мобильники не входят.

Да и кроссбраузерность порой страдает

От ajax'а? Имхо, ничуть. По крайней мере, не больше, чем от обычного оформления страницы. Думаю, здесь важно писать в соответствии с W3C DOM и постоянно проверять сайт на 3-4-х ведущих браузерах.

Всем спасибо за мнения и советы. Думаю, стоит довести идею до конца и решить задачу без post'а. Из описанных трудностей я не встретил особо ощутимых.

[s0rr0w]

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

Какое же это усложнение? Весь сайт может собираться тремя функциями!!!

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

Я написал API системы еще два года назад. Только сейчас переписал, но чисто из-за спортивного интереса. Вернее увидел небольшое упрощение, воспользовался.

С тех пор дописал всего ОДНУ функцию и добавил один патч. Все. Пишите универсальные вещи, не придется постоянно доделывать.

Ты не понял, HTML то можно присылать, но это же все-таки скрипт: onclick="doRequest('news'); return false;". Но это уж ладно, этим можно пренебречь.

Скрипты можно присылать даже не в CDATA, а как значение ноды, и выполнять их после вставки в основной документ.

Можно, но опять таки больше программирования, больше времени и т.п. чем в стандартном способе...

Это заблуждение. Программировать в разы проще и быстрее. И багов на порядок меньше.

Мне нравится твой взгляд, идеалистичный и оптимистичный, это и двигает прогресс. Но в реальности все не так просто получается...

Система, которую мы разрабатываем, без проблем работает более двух лет. Построена как раз на данном принципе. Удовольствие от работы огромное. После своей системы мне gmail кажется убогой неудобной поделкой.

[Searcher]

Похоже, s0rr0w, ты меня стал переубеждать... Но для разработки универсальной модульной системы нужно свободное время, вот с этим пока туго...

Лёд тронулся

[s0rr0w]

Похоже, s0rr0w, ты меня стал переубеждать... Но для разработки универсальной модульной системы нужно свободное время, вот с этим пока туго...

Лёд тронулся

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

Например, подгрузка постраничных данных может выглядеть вот так:

1 шаг

<pager_top/>

<data_container/>

<pager_bottom/>

<script>

load data

</sctript>

2 шаг

<data/>

<script>

pager init

</script>

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

[Searcher]

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

[s0rr0w]

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

Ну да

А если у тебя нет постраничного вывода, то грузи просто данные, без обертки.

[Searcher]

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

Такая схема на проксях что-то подглючивала иногда, не догружала страницу...