Обработка radio buttons

[wrbanker]

Документ формирует клиент. И у меня тогда тогда ещё есть вопрос.
Документ формируется не просто из конкретных ответов. Например, есть два поля - одно с checkbox, а второе с radio. В зависимости от того, что и где отмечено в обоих этих полях и будет добавляться в документ тот или иной абзац. Поэтому, видимо, у меня и есть желание объявить какие-то понятные переменные, записать в них зависимые от заполнения полей формы значения, и уже дальше с ними работать.

Возможно, что вы уже ответили на все мои вопросы и я просто не понимаю ответов. Но последний язык программирования, на котором я решал задачи, был Fortran 4 (да, мы ещё живы)

[laimas]

Документ формируется не просто из конкретных ответов. Например, есть два поля - одно с checkbox, а второе с radio.

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

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

{"имя_поля": ["Абзац 1", "Абзац 2", "Абзац 3"]}

где индексы абзацев, это сумма значений ответов (0 не выбрано, 1 выбрано) или иным принципам сформированные.

То есть, получить и сформировать можно сразу, зачем сначала что-то чему-то присвоить, а затем еще и с ним разбираться.

[wrbanker]

Да, вы правы. Думая, что это мне задачу упростит, я её усложняю. Буду пробовать без "посредников". Надеюсь, что получится.
Спасибо!

[laimas]

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

[wrbanker]

Структура уже есть. Мы с коллегой её уже сочинили. Я вот теперь её пытаюсь в JS воплотить

[wrbanker]

Да, подозреваю, что следующий серьёзный затык у меня возникнет с формированием итогового PDF-документа. Если знаете, что в этом может помочь (помимо библиотеки Pdfmake - про неё я знаю), буду признателен.

[laimas]

Структура уже есть.

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

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

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

Например, группируем поля в элементах 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. Если это объект, то это ссылка на функцию, в которую нужно передать значения/состояния полей, а функция вернет результат. В этом случае просто будет добавить функцию для обработки любых индивидуальных условий, а в атрибуте ссылку на нее. Сам автомат переписывать не нужно будет.

То есть структура это не просто набор вопрос/поля, а подчинена определенному конечному автомату.