Some time ago I needed to add clientside validation to a registration form. Aside of js-only validation there was a requirement for server-side validation, e.g. to check if a value entered into a field is unique. So a custom Feaval (https://www.drupal.org/sandbox/kpv/2223739) module appeared. After that I needed to integrate it with actual clientside_validation (1.x). Eventually it was done but with many hacks. To avoid those hacks a custom version of clienside_validation named Csval (https://www.drupal.org/sandbox/kpv/2231447) was born :)
So what is it all about.. It seems that those two custom modules could be useful for the community.

Some notes:

  • Feaval and Csval have mostly the same architecture.
  • Csval doen't use jquery.valdate plugin any more.
  • Validation rules are added using plugins:
  • First, there are plugins for field_type+widget_type pairs and form generic elements (present in both Feaval and Csval). These plugins manage form changes depending on field-widget type or form element (if not part of widget). Also it is a convenient way to extend (add support for other field-widget pairs) and override (use custom plugins instead of existing ones) functionality.
  • Second, there are plugins for js-rules (Csval only). Used to extend js rules applicable to given form element or field widget. Clientside field validation would be added using this type.

There are examples provided with the modules, pls see for more info.

Comments

kpv’s picture

kpv CreditAttribution: kpv commented
Issue summary: View changes
Jelle_S’s picture

Jelle_S
Primary language Dutch
Location Antwerp, Belgium
CreditAttribution: Jelle_S commented

Please have a look at the 7.x-2.x branch of clientside validation.
It's a major rewrite using libraries to load the jquery.validate plugin and ctools plugin for the php logic.
We're prepping for an alpha release soon.

attiks’s picture

attiks CreditAttribution: attiks commented

@kpv if you think we van re-use parts of tour sandboxes, feel free to say so or provide patches.

kpv’s picture

kpv CreditAttribution: kpv commented

Thanks for quick reply!
Here is the aproach in general terms:
A form consists of a number of form elements: generic elements (textfield, select, etc.) and field widgets. When form is prepared, a check is performed to find elements that require validation. For generic elements check is done at hook_form_alter(), for widgets - at hook_field_widget_form_alter(). For each element (that requires validation) a correspoinding plugin is looked for. If plugin exists, an #after_build function is attached to it. The task of #after_build is to a) attach plugin info to the element and b) add validation rules (js-validation) or set #ajax api settings (ajax-validation).
Js-rules are then processed on client side. jquery.validate plugin could be used for that (though it has its limits).
Ajax settings are processed by drupal ajax js. When an event is triggered on an element (e.g. focusout), ajax request is sent to server side. At that point corresponding plugin sets validation scope (subarray of $form that corresponds to the triggering element) and _form_validate() performs validation on it. If errors appear, the last one is sent as ajax response to client side where it is displayed to user.
As I understand, this aproach doesn't fit well into 2.x branch.

Jelle_S’s picture

Jelle_S
Primary language Dutch
Location Antwerp, Belgium
CreditAttribution: Jelle_S commented

Actually the 2.x branch is quite similar.

In hook_form_alter we add an #after_build to the form.
In the after build we loop (recursively) through all the elements and for each element we find the plugins that support it.
We pass the element to the plugins by reference (which means you can add '#ajax' to the element if you write your own plugin) and the plugin returns the js rules and messages that go with the rules.