Обработка radio buttons
Приветствую.
Стоит задача: показать выбранное значение radio. Работает только при выборе первого переключателя. В остальных случаях показывает, что переключатель не выбран. Помогите, плиз, понять где ошибка. <form id="test-form"> <ul> <li><input type="radio" name="radio-button" value="one"></li> <li><input type="radio" name="radio-button" value="two"></li> <li><input type="radio" name="radio-button" value="three"></li> </ul> <input type="submit" value="Обработать"> </form> <script> const form = document.querySelector('#test-form'); form.addEventListener('submit', function (event) { const testValue = (this.querySelector('[name="radio-button"]').checked) ? this.querySelector('[name="radio-button"]').value : 0; alert (testValue); }); </script> |
const testValue = this.elements['radio-button'].value; |
Цитата:
const testValue = (this.querySelector('[name="radio-button"]').checked) ? this.elements['radio-button'].value : 0; |
Цитата:
Если их несколько, надо использовать querySelectorAll - получить ВСЕ элементы и перебирать их в цикле. |
Цитата:
const testValue = this.querySelector('[name="radio-button"]:checked').value Тогда у меня ещё один вопрос. Можно ли обойтись без цикла, чтобы переменной присваивать значение radio, которое отмечено и '0' если не отмечено ничего? Через условное ветвление, например? |
Цитата:
Какова вообще цель, может вы делаете то, без чего вообще можно обойтись? |
Цитата:
|
wrbanker, так задачи не описывают, это просто рассказ о нулях.
У вас форма, у нее поля, если нужно привести соответствие состояния неких переменных состоянию полей, значит простой обойти поля циклом и ... Но для этого нужно связать сами переменные с полями. В тоже время почему имена полей и их значения не могут сами служить таким набором? |
Ок, попробую описать задачу иначе. Есть страница с условной анкетой. После её заполнения пользователь нажимает кнопку и получает документ, который определён его ответами.
Я думаю, что перво-наперво необходимо отловить все его ответы и присвоить зависимые от ответов значения переменным. Далее, анализируя значения переменных, формировать документ. Возможно, что я не прав. |
Вот это уже ближе к телу, а тут два сценария - если этот документ готовит сервер, то то что вы делаете на клиенте лишено смысла. Серверу нужно просто отправить форму, он должен анализировать что пришло. Если документ готовится на клиенте, то зачем посредник в виде 0 и ... Формируйте документ, в который вставляйте нужное, получая ответы из обхода циклом полей формы.
|
Документ формирует клиент. И у меня тогда тогда ещё есть вопрос.
Документ формируется не просто из конкретных ответов. Например, есть два поля - одно с checkbox, а второе с radio. В зависимости от того, что и где отмечено в обоих этих полях и будет добавляться в документ тот или иной абзац. Поэтому, видимо, у меня и есть желание объявить какие-то понятные переменные, записать в них зависимые от заполнения полей формы значения, и уже дальше с ними работать. Возможно, что вы уже ответили на все мои вопросы и я просто не понимаю ответов. Но последний язык программирования, на котором я решал задачи, был Fortran 4 (да, мы ещё живы):) |
Цитата:
А ответ вы получить можете только проверив значение полей. Так почему нельзя сразу при анализе полей сформировать конечный результат, а делать это чрез сторонний набор? Если у вас условие проверить определенный набор радио и флажок к нему, то вы же в любом случае должны знать имя и набора, и флажка, так ведь. А значит в цикле, если имя поля соответствует этому набору, то напрямую обращаемся к флажку для него, анализируем и определяем соответствующий текст. А можно сделать и так, без анализа детального, а использовать ваши 0 и 1, но также сразу в цикле, не присваивая их неким переменным, а получать сразу нужное. Например, ваши абзацы определяются в объекте описанном как: {"имя_поля": ["Абзац 1", "Абзац 2", "Абзац 3"]} где индексы абзацев, это сумма значений ответов (0 не выбрано, 1 выбрано) или иным принципам сформированные. То есть, получить и сформировать можно сразу, зачем сначала что-то чему-то присвоить, а затем еще и с ним разбираться. |
Да, вы правы. Думая, что это мне задачу упростит, я её усложняю. Буду пробовать без "посредников". Надеюсь, что получится.
Спасибо! |
wrbanker, составьте структуру, которая описывает абзацы и прочее для документа и зависящие от значения полей, так, чтобы можно было автоматически на основании значений обращаться к ним. Вот это сложнее будет, "придумать автомат", а написать его будет проще.
|
Структура уже есть. Мы с коллегой её уже сочинили. Я вот теперь её пытаюсь в JS воплотить :)
|
Да, подозреваю, что следующий серьёзный затык у меня возникнет с формированием итогового PDF-документа. Если знаете, что в этом может помочь (помимо библиотеки Pdfmake - про неё я знаю), буду признателен.
|
Цитата:
Если автомат, значит данные должны иметь признаки, по которым можно будет выполнять одну и туже операцию в автомате не зависимо от того какие данные, какое их количество. Они также должны определяться оговоренному набору. Если у вас по условию есть группа значений и плюс к ней еще некоторое значение, то само собой напрашивается группировка. Поля формы каждого вопроса анкеты должны быть группой. Каждая такая группа имеет одни и те же характеристики, по которым будет работать автомат. Например, группируем поля в элементах fieldset. Не важно, что у вопроса анкеты может быть только одно поле, оно все равно должно быть помещено в fieldset. Это оговаривается правилом, условием автомата. В fieldset в оговоренном атрибуте, например, data-fields описаны имена полей, значения которых надо получить/проверить... <fieldset data-fields="neme1,neme2"> Не важно что поле одно, оно все равно в этом атрибуте должно быть описано в этом атрибуте. Автомат получает коллекцию fieldset, обходит циклом, извлекает имена полей из data-fields и получает их массив. var fields = elm.dataset.fields.split(','); Обходит их циклом, в котором можно узнать все о нем, и имя, и тип, и значение - form[fields[i]].name, form[fields[i]].type, ... Но в таком подходе есть один минус - если одно правило, сложить значения полей или условия их состояния, то все будет нормально, но если для какого либо набора существуют какое либо правило, то такие правила описывать в самом автомате, это как запрограммировать ПЗУ, а затем ее стирать и перепограммировать заново. Но можно поступить ведь иначе - data-fields, это не просто текст, а json, в котором одно свойство описывает поля, а второе объект или значение false. Если это объект, то это ссылка на функцию, в которую нужно передать значения/состояния полей, а функция вернет результат. В этом случае просто будет добавить функцию для обработки любых индивидуальных условий, а в атрибуте ссылку на нее. Сам автомат переписывать не нужно будет. То есть структура это не просто набор вопрос/поля, а подчинена определенному конечному автомату. |
Часовой пояс GMT +3, время: 20:31. |