not 100% sure what "how should I structure the form description if I have to account for various deviations from the template" means
Let's look at the one-field input vs two-field input example. If all my inputs were one-field, I could describe the form in a relatively simple data structure:
[
{
id => 'alpha', numeric => [ 0, 1 ],
name => "Flux capacitance", units => ..., doc => ...,
# absence of default means it's required
},
{
id => 'beta', numeric => [ -100, +100 ],
name => "Bogon density", default => 0, units => ...,
doc => ...,
},
]
and have a both relatively simple loop in a template to generate a form and a straightforward way to validate once it's submitted. But a two-field input uncovers a conceptual difference between the form and the backend: in a form (for a user), both fields compose a single semantic unit ("Wavelength range"); for the validator, fields from a request are separate entities to be considered individually. If I prepare this description from the user's point of view ([ { name => "Wavelength range", ids => [ 'lowwl', 'upwl' ], ... }, ]), I make it harder for the validator to work ("now, where in one of those arrays can I find the parameter name I've just received?") and, arguably, I'm putting markup in the code, which is discouraged nowadays (what's next, putting CSS classes in the same form structure?). If I continue to work with this description from the point of view of the validator (as above), I cannot store the layout information for the generator to produce multiple fields per one conceptual "input".
Is what I'm experiencing Inner-Platform Effect in action? Should I give up and keep it simple, at the cost of some duplication? | [reply]
[d/l]
[select] |
<label for="[% fields.0.id %]">[% fields.0.name %] = </label>
<input
name="[% fields.0.id %]" placeholder="[% fields.0.placeholder
+%]" type="text"
id="[% fields.0.id %]" [% fields.0.required %] pattern="[% fie
+lds.0.regex %]"
>
[% FOREACH field IN fields %]
[% NEXT IF loop.first %]
<label> - </label>
<input
name="[% field.id %]" placeholder="[% field.placeholder %]" ty
+pe="text"
id="[% field.id %]" [% field.required %] pattern="[% field.reg
+ex %]"
>
<label for="[% field.id %]">[% field.units %]</label>
[% END %]
$fields = [{
id => 'loww1',
placeholder => 400,
...
}, {
...
}];
Hope this helps!
The way forward always starts with a minimal test.
| [reply]
[d/l]
[select] |
I don't see anything blocking you from passing in the array (with one element if there is only one) and using a Template loop.
Paraphrasing Tolstoy, all template-conforming fields are alike; each non-template-conforming field is different in its own way. One example I had provided involves multiple inputs per field; another might have a bunch of specialised CSS classes or require a small piece of JavaScript attached to it to provide necessary interactivity where available, and so on. If I try to write a template general enough to tend to all of them, it would be a mess, I expect. On the other hand, storing pieces of Template code (i.e. providing specialised mini-templates for non-standard fields) in the form description seems against interface/behaviour separation.
| [reply] |