not 100% sure what "how should I structure the form description if I have to account for various deviations from the template" meansLet'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:
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".[ { 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 => ..., }, ]
Is what I'm experiencing Inner-Platform Effect in action? Should I give up and keep it simple, at the cost of some duplication?
In reply to Re^2: Form generation and validation
by Anonymous Monk
in thread Form generation and validation
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |