jQuery plugin для форм с динамической структурой

[Groove]

Мысли материальны! Утром только подумал, что надо подобное сделать :)
Хотел использовать это zforms.ru/docs/repeatable-model/
Но заинтересовал и Ваш вариант

[jonie]

если вы их (данные с форм) будете сохранять, тогда в чем сложность-то?

[tushev]

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

[second_pilot]

В рельсах это не проблема благодаря nested_attributes. Кстати в тех же рельсах решал подобные задачи при помощи гема nested_form_for, который генерировал шаблон для формы, а так же умеет делать хелперы для ссылок или кнопок типа «добавить запись», которые собственно и генерируют новую подформу.

[Zippovich]

Наверное мне не так часто попадаются странные заказчики, как Вам. Я не вижу очевидного преимущества плагина перед самописом где нужно.
А вот прекрасную связку label — поле ввода по id Ваш плагин убивает напрочь.

[s0rr0w]

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

Не отнимают, если использовать несколько иные механизмы по работе с формами.

[s0rr0w]

Например, если использовать не селективную модель, как в jQuery, а событийную, и переложить обработчики событий на ноды, то формирование любых поведенческих моделей, как то выборка данных в json-структуры, формирование динамических строк любой формы и содержания, и прочие «трудности» становится простым занятием.

[yroman]

Не кинетесь ссылочками на примеры или где почитать? Заинтересовало.

[yroman]

Почему было принято решение писать отдельный плагин, а не воспользоваться knockout js, добавив нужные байндинги например?

[tushev]

Хотелось сделать работу с формами максимально лаконично, т.е. минимально дополнительных аттрибутов и JS кода. KnockoutJS все же требует больше кода и меньше понятен верстальщику. (Я не эксперт по KnockoutJS, поэтому возможно меня поправят)

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

Думаю вы правы, тоже самое можно было бы сделать на базе KnockoutJS. Т.е. получилась бы обертка над KnockoutJS.

[HarpyWar]

Напоминает KnockoutJS, где это одна из его возможностей.

[Adiost]

Дабы избежать кошмара постоянного программирования всех этих кнопочек – «добавить», «удалить»

Огромное. Человеческое. Спасибо.

[TiGR]

А если задействовать html5 forms repeating model?

Можно использовать webshim (webforms2), который реализует это дело в любом браузере, пока производители не напишут поддержку repeating model из коробки.

[UseRifle]

Почему бы не назначать инпутам имена, такие как «product[productArray][0][title]» — тогда данные можно было бы собирать на сервере без js

[neochief]

Так работают формы в Drupal, кстати.

[nehxby]

Аналогичная мысль возникла. Постоянно пользуюсь такими именами для массивов данных — очень удобно на стороне сервера получать сразу массив. Отлично работает в РНР.
Знающие, удовлетворите любопытство — приходят ли данные в виде массивов и в другие веб-ориентированные языки?

[Zelgadis]

да

[cuhuak]

Нет. В ASP.NET MVC необходимо (для коллекций в первую очередь) формировать запрос по-другому

[tushev]

Да. Если хочится сабмитить форму без JS то такие имена очень кстати, если вы используете PHP.
Только лучше писать не

product[productArray][0][title]

а

product[productArray][][title]

Тогда массив будет автонумероваться.

Возможно мой плагин и в текущей версии переварит такие имена, хотя надо проверить.

[UseRifle]

цифра нужна, чтобы понять, где заканчивается одна запись и начинается вторая

product[productArray][0][title] product[productArray][0][price] product[productArray][1][title] product[productArray][1][price]

В ruby on rails тоже есть парсер таких конструкций, возвращает хэш. который влегкую скармливается в нестед ресурсы

[bO_oblik]

Делал такую штуку для xml, от рекурсии голова чуть не взорвалась.

[impass]

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

[tushev]

Я бы так не сказал. Как правило, по сравнению со всем остальным — валидация это просто.

В большинстве случаев для валидации достаточно с каждым полем сопоставить регулярное выражение. Собственно я хочу добавить обработку таких атрибутов в следующей версии. Типа того.

<input name="login" data-regexp="/^[a-z0-9]{6-9}$/" data-regexp-message="Incorrect login" />

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

[UseRifle]

В основном да, не важно.

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

Кроме того, валидация на сервере в любом случае же будет производиться.

[impass]

Имелось ввиду server-side. Без этого, сами понимаете, никуда. Либо вы закрываете глаза на дыру размером с окно.

[tushev]

Сервер-сайд валидация зачастую пишется проще чем клиентская. На сервере больше возможностей.
.