Re: Form generation and validation

Form building libraries have always been a trade-off… They are powerful and can be wonderful in result but in any non-trivial implementation they take so much configuration and such that it ends up just being another (slow) mini-language on top of the template’s mini language on top of Perl and probably with a bunch of JS, and now HTML5 extensions, in the mix.

A well behaved model on the backend should do its own validation—so I say—and that means another layer of validation which is not DRY and is ripe for bugs by schism. I was a sometimes fan of them but ended up drifting away and never missed it.

I don’t have a best practice recommendation but I will say that backend based form building libraries are probably a mistake unless they are integral to the full framework and there is nothing like that in Perl. More and more in JS… If you really want to use a form builder, CSS is extremely powerful and fairly x-browser reliable today. I would still push validation to the model/data layer. It’s the most natural and reusable place for it. Also, I would never use the input pattern property. It is invisible to the actual ~~victim~~ user of the constraint so it’s not good UX and it surfaces your code or expectations to hackers and the client side checks can be bypassed with direct requests/POSTs and regular expressions can be exploited maliciously.

Update: also be careful. ALL user supplied data must be escaped. It’s opt in in TT2. So, anything that comes from params, etc, needs something like: [% name | html %]

Update: typoeses.

Comment on Re: Form generation and validation Download Code

Replies are listed 'Best First'.
Re^2: Form generation and validation by Anonymous Monk on Jul 26, 2019 at 20:18 UTC
A well behaved model on the backend should do its own validation Yes, I will do the validation in the backend, especially since the web app is going to be a front-end for a fairly fragile C++ executable. (The original design was to glue this executable with some C CGI library; we have since decided to use a real web framework.) I would still push validation to the model/data layer. It’s the most natural and reusable place for it. Agreed. What also worries me is the correspondence between `<input name="...">` tags in the form layout and the expectations of the model (`query_parameters->get("...")` in Dancer terms). Is there a way to enforce it, besides form generation and various forms of testing? I can easily imagine a typo squeezing in one of the rarely used parameters. Making it relatively painless to add new parameters would also be nice. Also, I would never use the input pattern property. It is invisible to the actual user of the constraint so it’s not good UX and it surfaces your code or expectations to hackers and the client side checks can be bypassed with direct requests/POSTs and regular expressions can be exploited maliciously. Noted. Does it mean that good client-side validation has to be done in JavaScript? I'm only doing client-side validation for the sake of the user ("prevent errors instead of presenting error messages after the error happened"), but I have personal aversion to client-side scripting (which I can overcome if the job needs it). For most fields, I would be okay with the client being able to verify that a field contains a floating-point number, but browsers are not up to it yet. ALL user supplied data must be escaped. It’s opt in in TT2. So, anything that comes from params, etc, needs something like: `[% name \| html %]` Thanks for the reminder. I omitted that in the OP for simplicity, since I was typing code from my head, not having any form backend code yet.	[reply] [d/l] [select]
Re^3: Form generation and validation by 1nickt (Canon) on Jul 26, 2019 at 21:12 UTC
You can and should do some validation on the page in the user's browser, but as noted the real bulwark is the backend. On the other hand you can do it very close to the request arrival so your app doesn't really fire up unless needed. Since you are (rightly) concerned about strict param validation and it sounds like a serious app, I would start out right and create an OpenAPI spec for the app defining the routes and the acceptable params. There are plugins for Dancer which will build the whole app from the spec! And then validate the input if desired, etc. There's no reason to wait until the data is received by a route handler to validate it. The way forward always starts with a minimal test.	[reply]
Re^4: Form generation and validation by Anonymous Monk on Aug 01, 2019 at 11:24 UTC
Thank you for linking me to OpenAPI specifications! This looks like an interesting idea to pursue, especially since I expect to provide some kind of API in addition to the web page in the future.	[reply]