вадяПрограмёр,
да я не спорю.
просто ответь для чего нужен этот плагин?

Для того же, для чего нужен ajaxForm. Только этот плагин позволяет ещё меньше обслуживающего кода писать. По сути просто прицепил его к форме или селектору, описал обработчики событий и готово :) Ну и разумеется ajaxForm не реализует автоматический вызов разных обработчиков и их смену "на лету"

Отличительная черта от большинства jquery плагинов это то, что он может быть повешен не только на конкретный массив элементов, который существует в момент вызова, а может и цепляться к "селектору", что позволяет вызвать его функцию один раз и как только какая-то из форм попадёт под правило (под селектор), она тут же зацепит указанный функционал.

Считаю что так намного удобнее.

удобства плагина на данный момент
То есть в целом удобства плагина на данный момент (хотя он ещё зелёный до невозможности):
1. Подключение в одну строку
2. Не добавляет лишнего html кода
3. Лёгкий в настройке
4. Может подключаться по селектору без необходимости повторного вызова для подключения к новым формам (делегирует обработку событий)
5. Лёгкое отключение от формы в случае необходимости (многие плагины вообще не предусматривают возможность отключения)
6. Позволяет менять обработчики ответов сервера для разных форм "на лету".

вадяПрограмёр,
заметь, ты даже не упомянул о применении данного плагина в mvc.

Может мне надо было ещё про шаблон мост или декоратор вспомнить? :))

В общем не понял к чему ты это сказал, но прозвучало это не круто :)

вадяя не проит применять разные подходы.
тут уже писали про кроиков и гаубицы...

Вадя, как часто ты в своей работе используешь наработки других программистов? Часто ведь? взять даже ту же openCMS или как там её. :) Ты ведь не сам её писал, но в работе пользуешь. А теперь представь, что у тебя её не было и тебе пришлось бы придумывать и писать её с нуля. Это лишние затраты?

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

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

Какие-то двойные стандарты прям. Чем этот интеллектуальный труд отличается от интеллектуального труда вложенного в код OpenCMS?

Разумеется дело каждого какие инструменты использовать, но я могу назвать уйму причин почему следует в работе пользоваться чужими уже проверенными наработками, а не создавать свои собственные. Исключение - если чужие наработки не решают имеющиеся задачи или накладывают ограничения (например правовые)... Но сейчас их столько, что зачастую каждую задачу можно решить просто погуглив :)

вадяПрограмёр,
в твоих словах много мудрости. и я со многим согласен, но позволю себе несколько не привычныйдля некоторых товарищей подход,
я не отрицаю всю прелесть и возможности их методов, хочу и от них адекватного отношения.
из опыта акса я вынес необходимость качественного построения базы- таблицы, связи , индексы .
и только потом всё осталное , в аксе все строится на обработке (отображении результатов) запросов к базе. единственное что там мешало - невозможность работать через веб
ws снимает это ограниение. есть база, есть хранимки обрабатывающие данные и возвращающие готовые для отображения данные.
js позволяет сформировать данные для зпароса в удобном виде - ws передать на сервер, на сервере запустить хранимку и отдать результат.
посты в ветке по java и тут позволяют сделать вывод, что работа с базами это ахилесова пята. очень и очень низкий уровень. для меня же получить нужные и удобные для отображения данные (тем более в хранимке) не проблема.
по сути получается двухзвенка. в аксе такое считается правильным там куча запросов к базе/серверу.
стоимость запроса с использование ajax , несколько лет назад, до jquery, была очень высока, поэтому от них и отказались в пользу других методов, но новые методы jquery и ws (тем более) позволяют взять многое из старого, развитие идёт по спирали.
и проекты в аксе строили и строят не одиночки и сложность проектов достаточна, поэтому опыт из акса я считаю отвергать не стоит.

"я не отрицаю всю прелесть и возможности их методов, хочу и от них адекватного отношения" - кого "их"? )) Если ты о том, кто паттерны придумывает общеизвестные, то я очень сомневаюсь что они на этом форуме сидят. Зачастую эти ребята русского не знают :) Так что странно ожидать от них, что они прислушаются к каким-то из твоих слов... они их просто вероятнее всего не услышат

"из опыта акса я вынес необходимость качественного построения базы- таблицы, связи , индексы" - согласен, но темы не касается :)

про БД комментировать не хочу, потому что снова застрянем на споре по бд, а мне это поднадоело...

а вот дальше интереснее:
"стоимость запроса с использование ajax , несколько лет назад, до jquery, была очень высока, поэтому от них и отказались в пользу других методов" - история jquery . Как видим jquery умела работать с ajax уже в январе 2006 года (11 лет назад!!!). Сам ajax стала официальной технологией в начале 2005-ого... и ничего там сложного и затратного не было... я первый год работы программистом противился разным фреймворкам, а потому точно знаю как с ajax без jquery работать :)) Да и всё остальное без jquery делать могу на чистом js.
А до того, как в js добавили XMLHttpRequest, был ещё такой прекрасный элемент как iframe. Его использовали даже когда XMLHttpRequest уже был.. для отправки файлов использовали, так как этот новый объект не давал такой возможности. Так вот, iframe вообще фиг знает когда появился... я ещё будучи совсем малым (лет 14 назад) когда только приступал к изучению программирования и иногда с html и js дурачился, он уже там был. Пишут что майкрософт его добавила ещё в 96-ом году... думаю другие не намного позже :)

Как-то не очень правдоподобно причина выбора других технологий звучит. Больше смахивает на "просто не знал что можно иначе" :) Так что никакого "по спирали" тут нет. По спирали идёт история, мода (и дизайн в целом) и другие гуманитарные направления. Я не представляю себе что значит пойти по спирали в науке про информацию или в математике... Это значит просто забыть несколько десятков/сотен лет наработок? Зачем тогда такая наука? :))


P.S. не знаю правда ли, но помню не раз слышал что access самая убогая из всех существующих СУБД :) Сам в ней не работал, но учитывая такой настрой общества против этого инструмента - далеко не факт, что принимаемые на его основе решения являются хотя бы близки к оптимальным... Кстати, я тут поглядел статистику использования СУБД... MS Access где-то далеко-далеко. Процент настолько мал, что она даже в рейтинги зачастую не включается. Или её переименовали? (нашёл только в одном рейтинге, где она занимала 0.4% от общего числа... рейтинг использования в отделениях федеральных органов власти в россии... в остальных рейтингах она отсутствовала).