We are discussing implementing data entry validation on client side.
We are interested in most basic validation like email, numeric fields, phone numbers. We’d need external validations ( AJAX ) for support special fields.
So far there’s a minimal validation implemented in LBF, that seems to work for name field only. There’s also template for patient external ID.
What are the community’s standpoint? Were there any attempts or unfinished development for client side validation?
For the implementation itself we suggest to use validate.js library that does not require jQuery.
There’s also jQuery validation plugin, but the problem of using multiple jquery versions makes it unreliable.
That is excellent idea. One of the basic challenge with this project is it uses various engines that contributors were familiar with at a given point in time. So you have basic php (in various flavors), code generated by xml specs, dynamic code generated by layouts in database, smarty, zend and maybe others. On top of this diversity, lack of php classes has driven need for situation specific code.
This comment is not meant as crtique but as input to scope definition. Last few years have been consumed by achieving Meaningful Use certification functionality over any plumbing repairs.
For anything to make immediate impact with minimal / no code modification, if a high quality / functionality library is available through jQuery, you could consider use of named global instance as suggested elsewhere to isolate core functions from existing code. Validators get attached on document load. Integrating this feature in existing code would then consist of adding a validattion class to display element and removing exising validation code (if any).
validate.js may be useful, I don’t know enough about it to say. I’ve done validation logic from time to time just by writing JavaScript, and sometimes this has involved generating JavaScript objects and arrays with PHP code to handle “interesting” cases. Honestly it’s never occurred to me that this is a difficult problem that needs a third party solution.
More generally, I have some opinions. There’s a lot to be said for refactoring and modularizing logic of all types. It’s too often the case that things get done on a deadline, intending a later cleanup that never happens. The cleanup needs to happen at the base level via funding for infrastructure work, and in the long run treating the code as a black box and layering solutions on top of it will only make things worse.
Hi again,
I have attached the best excuse for DD that we have.
Basically what we propose is:
to bring validate.js
allow to add validation rule(s) for every LBF field
Then individual contributors can re-write, if needed, validation in custom modules and non-LBF forms.
We are hoping to initiate discussion here and we would appreciate community feedback.
( Fixes for my English grammar can be send in private messages
It may be better to have the list of standard validations in the cached .js file rather than repeating same at LBF field level. If e.g. “dt_past” is ‘{ type: date, format: “YYYY-MM-DD”, past: true }’, you can control the validation globally. LBF table will contain list of optional standard validations for each field rather than full json code for every field. Other forms can also reuse the same validations. Use jQuery to link the validations based on classes or any of other generalized developer tricks.
If you need to support translations of the messages within a pure javascript file using the OpenEMR translation engine; ZH Healthcare implemented a gem of a mechanism in the Care Coordination module to do this. Do a grep for “function js_xl” to see the function and how it works.
In the layouts gui, for the error message translations, recommend taking same approach that is currently used there for titles and decriptions (a column shows what the translation would look like).
On the out of box default settings, will be important to support full internationalization. Meaning, should not have filters turned on that work well in US/Hebrew, but break in other places. This has been an issue with validators in the past and why not many of them have made it into the codebase. Your strategy of making it configurable and not latin encoding centric sounds very good.
I think validation of LBFs is a great start. I envision the validation mechanisms would have to be configured form the LBF form builder, and you could pick one or more client-side validation options for each field (required, alpha, regex, etc.). Then a class or attributes would be appended to the form element that could be interpretted by whichever validation library is chosen.
