AJAX. Небольшое обобщение опыта.

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

LitePHP

echo $variable; echo 'some text'; echo "some\ntext\nwith\nbreaks";

Об этом документе: (Куча бесполезного дерьма)

Да уж, документ ни о чем... Подобного в Сети - море

Только начинаю учить JavaScript + AJAX + PHP.

Спасибо за краткое и четкое введение + пример.

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

P.S. На обращай внимания на "наезды" - вернее обращай и пытайся вытянуть из них рациональное зерно, пропуская мимо ушей глупости и всяческое выпячивание своей "крутости".

Я бы предпочел более подробную информацию по фреймворкам. Prototype, JQuery, script.aculo.us, Yahoo UI ну и все в этом роде...

> Я бы предпочел более подробную информацию по фреймворкам. Prototype, JQuery, script.aculo.us, Yahoo UI ну и все в этом роде

Очень хорошо, что вы вспомнили эти фреймворки.

Данная отписка создавалась ещё с одной целью.

По работе я постоянно озабочен проблемой оптимального использования ресурсов(не в Газпроме работаю). И я свято верю в то, что:

любая задача должна быть выполнена: 1) Согласно ТЗ 2) В установленные временные рамки 3) В установленном ценовом диапазоне

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

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

> а) бюджет проекта резиновый и можно не скупиться на высококвалифицированные кадры

Вот этот момент поподробнее осветите пожалуйста... Т.е. если бюджет не резиновый, то работу выполняют низкооплачиваемые низкоквалифицированные кадры? Хмм... (с) железко

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

ЗЫ лично я незнакомые технологии осваиваю дома, зато потом очень приятно без запарок быстро и качественно делать свою работу :)

>JSON хорош тем, что на стороне клиента его не надо обрабатывать каким-то специальным образом, достаточно выполнить вызов функции eval(). Однако, исходя из соображений безопасности, его необходимо анализировать, так как при передаче вредоносного кода функция eval() выполнит данный код.

А чем плох JSON.parse()?

P.S. Никто случаем не натыкался на статейки, где описывается подход к автоматической генерации обработчиков форм, передача обработчиков прямо в response и т.д.?

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

Да, зачастую это неизбежное следствие.

> Я, честно говоря, думал, что фреймворки создаются для облегчения процесса программирования, а не наооборот.

Бесспорно. Вопрос только какие задачи он должен решать. Вряд ли для задач ресайзинга изображений нужен фотошоп.

> Или у вас исполнители меняются от проекта к проекту и ставок на опыт/знания/умения делать не приходиться? Или же они зациклились на одном месте и выше уже никак?

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

p.s. квалификация это, прежде всего, способность решать поставленные задачи точно в срок, а не суммарная масса чисто теоретических знаний. И из 2х программистов тот более квалифицирован, который решил задачу качественно и в срок, а не тот, который не уложился в сроки, сделал что-то тормозное и глючное, но зато применил какую-то передовую разработку, чтобы не изобретать велосипед (да и никому не будет интересно, что там было применено).

Всё это хорошо, главное не забывать, что и при отключенном javascript информация должна отобразиться у пользователя, поэтому ссылки вида <a href="#"... не есть хороший тон.

Хм ... верно подмечено. В ближайшее время подправлю.

>Рассматривая различные ajax-фреймворки отсекал неоправданно тяжёлое, запутанное, нефункциональное (например лесом пошел XML)

AJAX - Asynchronous JavaScript and XML... Интересно каким лесом этот самый xml у Вас пошел? :)

Сосновым :-)

Буду признателен, если представите хоть одно преимущество XML, при использовании его для асинхронного обмена данными между браузером и web-сервером. Только если для того, чтобы оправдать название.

Хотя бы то что ответ сервера можно распарсить средствами DOM. В случае если передается pure html - а ведь это и есть xml документ (правда если он валидно написан). И потом - взаимодействие с SOAP based web services тоже имеет значение.

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

А XML действительно идет лесом - тут это из пушки по воробьям, тем более дико неудобно использовать в клиент-сайд скрипте. Решение? Очень простое - JSON. В двух словах: ответ на XMLHTTPRequest генерируется как строка, представляющая собой js-овый список или хэш, легким движением eval'а превращаемая в исходный объект. Экономия траффика, удобство, скорость и универсальность налицо.

По сути вопроса - еще один велосипед, тем более далеко не самый лучший и универсальный. Привык все аяксовые и не только функции класть на плечи Prototype, затрат сил и необходимость писать лишний код будет объективно гораздо меньшей чем при использовании представленного подхода.

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