Re^2: Form generation and validation

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 => ...,
 },
]
[download]

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?

Comment on Re^2: Form generation and validation Select or Download Code

Replies are listed 'Best First'.
Re^3: Form generation and validation by 1nickt (Canon) on Jul 26, 2019 at 19:53 UTC
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. <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 %] [download] `$fields = [{ id => 'loww1', placeholder => 400, ... }, { ... }];` [download] Hope this helps! The way forward always starts with a minimal test.	[reply] [d/l] [select]
Re^4: Form generation and validation by Anonymous Monk on Aug 01, 2019 at 11:21 UTC
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]