Comments 67
Симпатично. Только вот нет ни слова про лицензию.
Под какой лицензией можно использовать?
Под какой лицензией можно использовать?
Программистам, наверное, этот плагин будет хорошим подспорьем в работе. Вот только пользователи сильно удивятся, когда при выборе определенного значения откроется блок с еще «стотысячами» полей.
Может быть имеет смысл предусмотреть какую-то индикацию прогресса заполнения полей на уровне плагина?
Может быть имеет смысл предусмотреть какую-то индикацию прогресса заполнения полей на уровне плагина?
Выглядит небезынтересно. Вешать плагин можно только на форму или любой элемент подойдет?
Хорошая работа, а довелось ли сравнивать с сущестующими библиотеками, такими как knockout.js? На мой взгляд отличная реализация паттерна MVV на JavaScript
мне особо понравилась там observable pattern.
И да, очень пересекается имхо с этим плагином, разве что плагин в статье как-то полегче выглядит, но и сходу больше возможностей.
И да, очень пересекается имхо с этим плагином, разве что плагин в статье как-то полегче выглядит, но и сходу больше возможностей.
knockout.js очень хорош. Но мне не очень нравится что логика задается через атрибуты элементов, то-есть получается жуткая каша в которой одновременно описана и структура документа и логика обработки.
Спасибо, попробую в ближайшее время. Недавно была такая задача, решал методом написания «простыни» :)
Спасибо, буквально на днях возникла необходимость в таком функционале )
Не соглашусь насчет визарда. Мне как пользователю гораздо удобнее заполнить 10 махоньких формочек, чем одну большую, которая к тому же еще и меняется как-то динамически.
UFO just landed and posted this here
фича конечно. Зачем прятать то что пользователь уже вводил.
UFO just landed and posted this here
UFO just landed and posted this here
Там другой «фиче-баг» назревает. Пользователь ввел данные в поле1, потом в поле2. Потом в поле1 данные стер и нажал на сабмит. На сервер уйдет поле1="" и поле2=«предыдущий текст».
Это, в принципе, не сильно парит, но можно будет нарваться на ситуацию, когда на сервер придет «задизейбленный» чекбокс с активным значением, который потом сломает что-нибудь.
Это, в принципе, не сильно парит, но можно будет нарваться на ситуацию, когда на сервер придет «задизейбленный» чекбокс с активным значением, который потом сломает что-нибудь.
Это вопрос корректной реализации на стороне сервера. По идее если поле скрыто, то его значение не важно и должно быть проигнорировано.
Возвращаясь к примеру в начале статьи, если выбран «самовывоз» то обрабатывать как-то «адрес доставки» нет смысла.
Возвращаясь к примеру в начале статьи, если выбран «самовывоз» то обрабатывать как-то «адрес доставки» нет смысла.
Это звучит неплохо, пока вам не придется сохранять 500 различных полей, половина из которых является динамическими формами. Вот тогда понадобится единый метод управления построением форм и ее валидации. Тут SVARX выглядит гораздо более привлекательным идеологически.
SVARX занимается только валидацией форм
описанный плагин занимается только динамическим изменением форм
Но вообще возможно и есть смысл воткнуть опцию типа «autoclear».
описанный плагин занимается только динамическим изменением форм
Но вообще возможно и есть смысл воткнуть опцию типа «autoclear».
Динамическое изменение форм и последующая валидация — последовательно идущие действия. Смотрите шире, не решайте только одну задачу из всего комплекса. На SVARX легче легкого навесить функционал динамического изменения форм, так как там присутствует достаточное количество информации для реализации задуманного. Так понятнее? Но вдобавок, SVARX решает и проблему валидации, что ваш плагин делать не умеет.
Это совсем не проблема. При скрытии полей им просто нужно добавлять атрибут disabled. Значения отключённых полей на сервер не посылаются.
<form action="" method="get">
<p><input name="foo" type="text" value="1" /></p>
<p><input disabled="disabled" name="bar" type="text" value="2" /></p>
<p><input type="submit" /></p>
</form>UFO just landed and posted this here
Данные нужны не вам, а серверу который будет обрабатывать введенные данные =)
Если логикой задано скрывание поля, наверное значение этого поля уже не важно и оно будет проигнорировано на стороне сервера.
Если логикой задано скрывание поля, наверное значение этого поля уже не важно и оно будет проигнорировано на стороне сервера.
Вполне предсказуемое поведение.
Есть же zforms
Программисты такие программисты…
Вопрос автору плагина. Пользователь наколбасил форму, сохранил. Как ее потом отредактировать?
Вопрос автору плагина. Пользователь наколбасил форму, сохранил. Как ее потом отредактировать?
Не уверен что понял описанный сценарий, но вообще если с сервера придёт форма в которой уже заданы значения некоторых полей, то ничего не поломается. Плагин пробегает по всем правилам после загрузки DOM.
Возможно вы упустили что плагин не добавляет или удаляет поля, прячет и показывает.
Возможно вы упустили что плагин не добавляет или удаляет поля, прячет и показывает.
Я ничего не упустил. Вы просто не все ситуации предусмотрели.
Открываем 4й пример. Выбираем Form, Type, Number. Постим данные на сервер. Как будет выглядеть эта же форма с уже заполненными данными, если захочется пользователю потом что-то изменить?
Опции Type и Number заполняются скриптом… И им нужно будет присвоить нужные значения. Как?
Открываем 4й пример. Выбираем Form, Type, Number. Постим данные на сервер. Как будет выглядеть эта же форма с уже заполненными данными, если захочется пользователю потом что-то изменить?
Опции Type и Number заполняются скриптом… И им нужно будет присвоить нужные значения. Как?
Хабр такой Хабр. Нашел принципиальную архитектурную багу, а это, судя по минусам в комменте, оказывается плохо… :)
Годный плагин. Но я бы еще дизаблил скрытые значения, или сделал возможность для этого.
>дизаблил скрытые значения
— всмысле затирать значения перед отправкой формы?
— всмысле затирать значения перед отправкой формы?
нет, всмысле выставлял disabled=«disabled»
1nd1go предлагает использовать «disabled», потому что такие поля не отправляются на сервер. Необходимость очистке полей отпадает.
Полезная вещь! В закладки.
А автора поздравляю с первой публикацией :)
А автора поздравляю с первой публикацией :)
Меня например раздражает что откуда ни возмись появляются новые поля ввода. Нужно этот момент додумать.
usecase:
ввожу название товара (выбираю из списка),
клиент отсылает запрос на сервер и если он есть в наличии — открывает форму оплаты,
а если нету — форму уведомления о поступлении.
ввожу название товара (выбираю из списка),
клиент отсылает запрос на сервер и если он есть в наличии — открывает форму оплаты,
а если нету — форму уведомления о поступлении.
Всё же немножко стрёмно с сохранением введённых данных…
Если логика такова, что всё что невидимо — является ненужным, то посылать серверу ещё кучу «ненужных данных», чтобы сервер их сортировал, убирал мусор и понимал что и как сохранять то:
1) Расходы траффика больше
2) Становится запутанной серверная часть, чего вроде бы пытались избежать
3) Белиберда в данных.
Например фирма регистрируется на сайте. Человек вначале затупил ввёл свой домашний адрес, потом вспомнил что он представитель конторы, выбрал в дропдауне Office вместо Home, ввёл адрес офиса и засабмитил, а сервер видит что поле с домашним адресом тоже не пустое и сохраняет и его, в результате офис имеет непонятно какой адрес. Не сильно кошерно как по мне.
Может всё же чистить данные?
А если вопрос в юзабилити, то тогда просто моно введённые данные хранить, а у инпутов просто убивать аттрибут name и тогда в сабмит они не попадут, и северер перегружать какой то заумной логикой не понадобится.
Если логика такова, что всё что невидимо — является ненужным, то посылать серверу ещё кучу «ненужных данных», чтобы сервер их сортировал, убирал мусор и понимал что и как сохранять то:
1) Расходы траффика больше
2) Становится запутанной серверная часть, чего вроде бы пытались избежать
3) Белиберда в данных.
Например фирма регистрируется на сайте. Человек вначале затупил ввёл свой домашний адрес, потом вспомнил что он представитель конторы, выбрал в дропдауне Office вместо Home, ввёл адрес офиса и засабмитил, а сервер видит что поле с домашним адресом тоже не пустое и сохраняет и его, в результате офис имеет непонятно какой адрес. Не сильно кошерно как по мне.
Может всё же чистить данные?
А если вопрос в юзабилити, то тогда просто моно введённые данные хранить, а у инпутов просто убивать аттрибут name и тогда в сабмит они не попадут, и северер перегружать какой то заумной логикой не понадобится.
1nd1go предложил вариант лучше. У спрятанных полей ставить disabled=«disabled», соответственно они не уйдут на сервер при отправке формы.
Ну как говорится алтернатива есть =) На счёт Disabled согласен, оно работает стабильно, а вот с name я не до конца уверен можно ли его менять/удалять. Точно помню что вот с полем type=password нельзя тип поменять, как с неймом не помню (но помоему можно).
В целом мне кажется плагин в хозяйстве пригодится, во всяком случае какие то тривиальные вещи сверстать будет куда быстрее, чем писать с 0, так что я себе кладу на полку, дабы не забыть =)
В целом мне кажется плагин в хозяйстве пригодится, во всяком случае какие то тривиальные вещи сверстать будет куда быстрее, чем писать с 0, так что я себе кладу на полку, дабы не забыть =)
Всё же немножко стрёмно с сохранением введённых данных…
Если логика такова, что всё что невидимо — является ненужным, то посылать серверу ещё кучу «ненужных данных», чтобы сервер их сортировал, убирал мусор и понимал что и как сохранять то:
1) Расходы траффика больше
2) Становится запутанной серверная часть, чего вроде бы пытались избежать
3) Белиберда в данных.
Например фирма регистрируется на сайте. Человек вначале затупил ввёл свой домашний адрес, потом вспомнил что он представитель конторы, выбрал в дропдауне Office вместо Home, ввёл адрес офиса и засабмитил, а сервер видит что поле с домашним адресом тоже не пустое и сохраняет и его, в результате офис имеет непонятно какой адрес. Не сильно кошерно как по мне.
Может всё же чистить данные?
А если вопрос в юзабилити, то тогда просто моно введённые данные хранить, а у инпутов просто убивать аттрибут name и тогда в сабмит они не попадут, и северер перегружать какой то заумной логикой не понадобится.
Если логика такова, что всё что невидимо — является ненужным, то посылать серверу ещё кучу «ненужных данных», чтобы сервер их сортировал, убирал мусор и понимал что и как сохранять то:
1) Расходы траффика больше
2) Становится запутанной серверная часть, чего вроде бы пытались избежать
3) Белиберда в данных.
Например фирма регистрируется на сайте. Человек вначале затупил ввёл свой домашний адрес, потом вспомнил что он представитель конторы, выбрал в дропдауне Office вместо Home, ввёл адрес офиса и засабмитил, а сервер видит что поле с домашним адресом тоже не пустое и сохраняет и его, в результате офис имеет непонятно какой адрес. Не сильно кошерно как по мне.
Может всё же чистить данные?
А если вопрос в юзабилити, то тогда просто моно введённые данные хранить, а у инпутов просто убивать аттрибут name и тогда в сабмит они не попадут, и северер перегружать какой то заумной логикой не понадобится.
так и не понятно как делать валидацию. например я использую серверный конструктор форм, могу по идее сразу всю форму сделать, а потом вашим плагин модифицировать. но если, например форма скрыта, то клиентская валидация, как правила биндить и снимать с поля? или я чего-то не понимаю?
Валидация — смежная задача, но плагин ею не занимается. Так сделано умышленно, чтобы не случилось ситуации указанной в этом этом комменте.
Столкнулся недавно с подобной задачей, несколько усложненной… Нужны были динамические и многошаговые формы, причем в зависимости от введенных параметров на предыдущих шагах, изменялось поведение последущих форм.
Проблему решил с помощью шаблонизатора на стороне клиента (плагин jQuery templates) habrahabr.ru/blogs/jquery/112843/
Кратко:
Есть структура вложенных шаблонов. От корневого шаблона до шаблонов отдельных элементов управления. Вся логика отображения элементов форм в том или ином случае задается в шаблонах.
Есть данные, которые загружаются в шаблон, и которыми оперирует шаблоны (использует их в логике, подставляет их в формы).
Теперь конкретно к задаче:
Нажали на кнопочку (должны появиться дополнительные элементы управления, поменяться текстовки, что-то еще)… Обработчик события обновляет данные и всего-то надо сделать ререндеринг корневого или группы вложенных шаблонов. Данные изменены, результат выполнения рендеринга шаблонов будет иным. Благодаря встроенным возможностям кэширования, ререндеринг происходит моментально.
минусы:
— плагин имеет статус beta, документации мало. Набил шишек.
— ошибки в шаблонах сложно находить.
— есть еще
плюсы:
+ наглядная и понятная логика в шаблонах.
+ огромная экономия трудозатрат на разработку сложных динамических форм. Думается, любыми другими известными мне средствами и плагинами моя задача была бы невыполнима за данное мне время.
++ до знакомства с jQuery templates решал данные задачи на чистом jQuery и сталкивался с проблемой, что при изменении объектов формы без перезагрузки объекта form давало множество побочних эффектов. Проблемы костылями решались — нехороший осадок остался. При использовании jQuery templates перегрушая корневой шаблон мы гарантируем, что объект form уничтожается и создается заново с видоизмененными элементами управления согласно логике. Побочних эффектов нет.
Проблему решил с помощью шаблонизатора на стороне клиента (плагин jQuery templates) habrahabr.ru/blogs/jquery/112843/
Кратко:
Есть структура вложенных шаблонов. От корневого шаблона до шаблонов отдельных элементов управления. Вся логика отображения элементов форм в том или ином случае задается в шаблонах.
Есть данные, которые загружаются в шаблон, и которыми оперирует шаблоны (использует их в логике, подставляет их в формы).
Теперь конкретно к задаче:
Нажали на кнопочку (должны появиться дополнительные элементы управления, поменяться текстовки, что-то еще)… Обработчик события обновляет данные и всего-то надо сделать ререндеринг корневого или группы вложенных шаблонов. Данные изменены, результат выполнения рендеринга шаблонов будет иным. Благодаря встроенным возможностям кэширования, ререндеринг происходит моментально.
минусы:
— плагин имеет статус beta, документации мало. Набил шишек.
— ошибки в шаблонах сложно находить.
— есть еще
плюсы:
+ наглядная и понятная логика в шаблонах.
+ огромная экономия трудозатрат на разработку сложных динамических форм. Думается, любыми другими известными мне средствами и плагинами моя задача была бы невыполнима за данное мне время.
++ до знакомства с jQuery templates решал данные задачи на чистом jQuery и сталкивался с проблемой, что при изменении объектов формы без перезагрузки объекта form давало множество побочних эффектов. Проблемы костылями решались — нехороший осадок остался. При использовании jQuery templates перегрушая корневой шаблон мы гарантируем, что объект form уничтожается и создается заново с видоизмененными элементами управления согласно логике. Побочних эффектов нет.
спасибо, интересно, но на пальцах сложно понять как там у вас всё работает =)
если интерес сохранится — пишите, расскажу поподробнее.
Хотя, если вы решаете задачу собственными инструментами — сложно согласиться на альтернативу.
Я бы задумался над таким вопросом: «А что если задача многократно усложнится?», т.е. появятся навороченные элементы управления на форме, например: динамические таблицы для ввода списков данных, с контроллами для добавления/удаления элементов или с ajax запросами по каждому элементу для ввода; усложните формы, как по количеству элементов управления, так и по связям между ними.
Будет ли ваше решение так же эффективно решать более сложные задачи, будет ли код легко читаем, а логика прозрачна?
В своем проекте, где был использован jQuery Templates, логика существенно усложнилась к моменту релиза (сложно было все в ТЗ предусмотреть)… Данный шаблонизатор позволил успешно бороться с возросшей сложностью)
Хотя, если вы решаете задачу собственными инструментами — сложно согласиться на альтернативу.
Я бы задумался над таким вопросом: «А что если задача многократно усложнится?», т.е. появятся навороченные элементы управления на форме, например: динамические таблицы для ввода списков данных, с контроллами для добавления/удаления элементов или с ajax запросами по каждому элементу для ввода; усложните формы, как по количеству элементов управления, так и по связям между ними.
Будет ли ваше решение так же эффективно решать более сложные задачи, будет ли код легко читаем, а логика прозрачна?
В своем проекте, где был использован jQuery Templates, логика существенно усложнилась к моменту релиза (сложно было все в ТЗ предусмотреть)… Данный шаблонизатор позволил успешно бороться с возросшей сложностью)
А какая совместимость с браузерами у этого плагина?
IE8 говорит
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322; MS-RTC LM 8; .NET4.0C; .NET4.0E)
Timestamp: Wed, 13 Jul 2011 14:37:06 UTC
Message: Object doesn't support this property or method
Line: 115
Char: 73
Code: 0
URI: h1d-demos.appspot.com/static/jquery-grewform/jquery.grewform.js
IE8 говорит
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322; MS-RTC LM 8; .NET4.0C; .NET4.0E)
Timestamp: Wed, 13 Jul 2011 14:37:06 UTC
Message: Object doesn't support this property or method
Line: 115
Char: 73
Code: 0
URI: h1d-demos.appspot.com/static/jquery-grewform/jquery.grewform.js
Я проверил плагин на реальном проекте. Действительно хорошая помощь в деле создания сложных форм.
Я нашел ряд ошибок (версия 0.0.2):
Строка 14, ошибка в названии переменной (
Строки 115, 477, вызов функции
Так же есть вызовы функции
Я нашел ряд ошибок (версия 0.0.2):
Строка 14, ошибка в названии переменной (
code вместо codes):jQuery('input,textarea').live('keyup change',function(e) {
var codes= [33,34,36,35,45,38,40,37,39]//arrows and others
if(e.keyCode && jQuery.inArray(e.keyCode,code)<0)//skip this keyUps to let this keys work as expected
jQuery(this).attr('value',this.value)
});
Строки 115, 477, вызов функции
trim объекта String. Этот метод ввели совсем недавно (если не ошибаюсь, в версии 1.8.1, Firefox 3.5), и далеко не во всех популярных браузерах (особенно понимаете где) он работает. Я бы заменил на jQuery.trim().Так же есть вызовы функции
debug, которая, к тому же, использует console, что вызывает ошибки в браузерах, где консоли нет.
эх, жаль не хочет работать с dreamhelg.ru/2009/11/fancy-ajax-contact-form/
понять почему знаний не хватает( не работает именно внутри контейнера формы, видно мешает какой-то из ее родных скриптов
понять почему знаний не хватает( не работает именно внутри контейнера формы, видно мешает какой-то из ее родных скриптов
Как я могу добавить свои селекторы? Например, мне нужно при выборе любого ненулевого значения из списка (select) показать другой список (select)? Спасибо
Не нужен для этого свой селектор: jsfiddle.net/kHgsp/1/
Sign up to leave a comment.
Плагин для «живых» форм