JS + WebServices

1. это баян, для этого даже куча библиотек есь - см. dojo или extjs

2. на тормоза, кучу уязвимостей, и гимморой ( последнее, если заюзаешь GWT или xml и подобную херь )

3. см 1 + юзать JSON для пердачи сообщений между клиентом и сервером и забыть про въебсервисы

а чем gwt плох?

> Насколько странно такое желание с точки зрения профи в данном вопросе?

Очень хорошее желание, я бы избил некоторых «погромистов» за нежелание так делать (вот как раз слил 80 метров «сайта», который бы уместился на 1 странице в 200кб)

На какие грабли можно наступить в глобальном плане?

Вил over 9000, но почти все они решаемые, а некоторые решения дают еще и профит дополнительный. Единственное исключение - это красноглазики/параноики отключающие JS, при этом требующие весь функционал, но таких исчезающе мало. Причем при должном умении у них будет минимальный функционал, только без рюшек.

Ну и конечно-же - какие библиотеки/фреймворки/технологии предложите для реализации серверной и клиентской стороны (особенно интересует клиентская сторона)?

Лучше всего - никаких. Хотя зависит от того, что именно тебе больше интересно: скорость работы, или скорость разработки

>красноглазики/параноики отключающие JS

это для интранета, так что можно диктовать условия.

Лучше всего - никаких. Хотя зависит от того, что именно тебе больше интересно: скорость работы, или скорость разработки

скорость разработки важнее.

угу, смотрю все это.
выбор неожиданно большой (в плане JS), глаза разбегаются.

3) gwt

http://www.linux.org.ru/forum/talks/4497412?lastmod=1265050675382

там

3. Можно написать свой велосипед - и опыта станет больше, и кода в разы меньше, и быстродействие выше, чем при использовании «фреймворков».

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

> за что здесь ругают xmlhttprequest

Есть еще куча способов отправки инфы на сервер, где уровень совместимости выше, а потоки данных еще меньше

Есть еще куча способов отправки инфы на сервер

Прошу хоть один пример, совместимый со стандартами (помимо обычных форм с указанием CGI-обработчика).

>Т.е. на сервере страницы не рендерятся, одна статическая страница с кодом на js

интранет система учета
интранет

Ну и какой смысл в одной статической странице тогда?

исключительно для практики.
надо же что-то новое осваивать)

>Прошу хоть один пример, совместимый со стандартами (помимо обычных форм с указанием CGI-обработчика).

Самое логичное - повесить js на submit формы и в нем пытаться заюзать xmlhttprequest или что тебе там заблагорассудится. Если не получается (браузер не оправдывает твох ожиданий и не поддерживает каких-либо наворотов), тогда вернуть true и данные формы пойдут как обычно, тем же POST-ом и с перезагрузкой страницы.

Самое логичное - повесить js на submit формы и в нем пытаться заюзать xmlhttprequest или что тебе там заблагорассудится. Если не получается (браузер не оправдывает твох ожиданий и не поддерживает каких-либо наворотов), тогда вернуть true и данные формы пойдут как обычно, тем же POST-ом и с перезагрузкой страницы.

Страницу перезагружать не надо - достаточно вывод обработчика формы направить в скрытый iframe нулевого размера (гугл, кстати, так и делает для «интерактивности»).

Я и сам иногда такую штуку использую: на форму загрузки файла нельзя повесить скрипт, который будет отсылать файл на сервер. Поэтому приходится вешать на нее CGI с выводом в пустой iframe. Скрипт-обработчик изменения содержимого формы file в момент отправки файла заполняет информационный div словами «Загрузка файла» и т.п., как только файл загрузился на сервер, тот отсылает веб-страницу с одним-единственным JS, изменяющим содержимое информационного div'а на «Загружено».

Ну, а во всех остальных случаях xmlhttprequest прекрасно справляется.

> Прошу хоть один пример, совместимый со стандартами (помимо обычных форм с указанием CGI-обработчика).

Прошу хоть одну ссылку на «стандарты». Если что, то ваш xmlhttprequest - грязный хак, от рождения.

Страницу перезагружать не надо - достаточно вывод обработчика формы направить в скрытый iframe нулевого размера (гугл, кстати, так и делает для «интерактивности»).

вообще, так делали многие, и еще до появления «аякса».

Прошу хоть одну ссылку на «стандарты». Если что, то ваш xmlhttprequest - грязный хак, от рождения.

W3C, конечно, и, кстати, xmlhttprequest вы называете грязным хаком? Стандарт, вообще-то.

sorry, ссылку оформил неправильно.

> и, кстати, xmlhttprequest вы называете грязным хаком?

Да. А тебе стоит поучить историю, если сам не застал тех времен: The concept behind the XMLHttpRequest object was originally created by the developers of Outlook Web Access for Microsoft Exchange Server 2000. An interface called IXMLHTTPRequest was developed and implemented into the second version of the MSXML library using this concept. The second version of the MSXML library was shipped with Internet Explorer 5.0 in March of 1999, allowing access, via ActiveX, to the IXMLHTTPRequest interface using the XMLHTTP wrapper of the MSXML library.

Стандарт, вообще-то.

Черновик, вообще-то. И да, в3ц окончательно скатился в говно.

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

Ослик хоть и ослик, но XMLHTTPRequest суппортит

> Если что, то ваш xmlhttprequest - грязный хак, от рождения.

xmlhttprequest прост в использовании, а то что он родом из мелкософта еще не дает повода называеть его хаком.

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

Недокументированная или нестандартизованная?

Т.е. вы признаете только то, что разработано комитетами? Напомню, что C создавался для написания UNIX и стандартизован был только в 1989, HTML создавался для обмена информацие в среде ученых и официально описан только в 1995 и т.д.