Development

ClientsideValidationAndFillin

You must first sign up to be able to contribute.

Version 4 (modified by lexor, 10 years ago)
--

clientside validation

The proposed approach

achieves the following objectives:

  • utilises existing configuration in validate.yml
  • adds little or no additional markup
  • is fully backwards compatible
  • outputs unobtrusive javascript
  • utilises html attributes to store validation hooks for javascript validation library. these attributes are added in the <head> using javascript and therefore are also unobtrusive and only present if the browser has javascript activated, and the code will also validate to W3C standards (no foreign attributes hard coded into the markup)
  • no additional form helpers required, work with existing from helpers
  • no additional configuration files

Requirements:

  • filter - sfClientValidateFilter
  • js - sfvalidation.js
  • additional settings in validate.yml

The filter

The filter works in the following manner:

  1. it performs an xpath query on the views content to find the forms in the view
  2. for each form in the view it then
    1. determines the forms destination module/action from its action attribute
    2. determines the forms method (post/get) from its method attribute
    3. loads the module/actions associated validate.yml file (cacheable)
    4. loops through the forms elements to determine if it has a name entry in the validate.yml file
    5. gives the form element an id if not present, and adds html attributes to this element (all elements attributes are added in a single script tag in the document head
    6. adds the script to the document head (this could be cached in an external .js file and simply included in later requests)

Therefore the outcome of the filter is all form elements in the view have the appropriate validation html attributes added via javascript, for a javascript validation library to read.

The validation and display

Deciding how to access these validation params and display errors are now the key topics of focus. Firstly lets look at the three main ways to display errors of a from:

  • show all errors in an alert
  • show all errors inline (next to, under/aboove, the form element or element container)
  • show all errors in a single container (usually at the top of the form)

All three above and combinations of can be shown onsubmit of the form.

There is also the additional option of displaying errors immediately, if the form element's value change, this is:

  • onblur (textarea, text)
  • onchange (radio, checkbox and selects)

Lets look at the various combinations of the above, the most likely are:

  • onsubmit show inline only
  • onsubmit show inline and container
  • onsubmit show inline and alert
  • onsubmit show alert only

Now all the above could also have immediate validation enabled, which will remove the error message if entered correctly after a submit, or display it as soon as the user has finished entering the data.

Configuration

So looking into the organising the configuration for this, there should be two variables:

screening:
  onsubmit: [(inline | alert | container),..] - multiple allowed
  onchange: (true | false)
  activate: (on|off)

Now onchange validation will have to be intelligent and understand which combination of onsubmit the dev has gone for, if they have chosen container and/or inline, then onchange must be sure to display the error in both these and clear these if no error, upon very change. If container and/or inline is chosen then alert will not be used onchange (that will look rubbish)

Extensions

  • Add params to choose an scriptalucious effect to display inline/container errors
  • Add param that after a submit hide valid fields or their container
  • Ensure that form only validates displayed fields and not fields that hidden display:none

See the following libraries for inspiration

Therefore whatever library we use (IMHO i think we can use the above as skeletons but need a home made one) it will have to search the dom for the form, read the configuration for that form from html attributes of the form (added by the filter), and then add the appropriate event listeners (onsubmit, onchange etc), which tranverse the forms elements (onsubmit) or element (onchange) and then read the html attribute hooks and do the validation, and display errors.

This javascript above is beyond me at the mo, but i got my filter working with a modified version of the zebda library, although it no longer works (doh!).

For the purpose of symfony, i think a good name for clientside validation could be screening (as in parameter screening)., as it shouldn't technically be relied upon for validation as javascript can be disabled as we know.

I have attached my very BETA filter that is pretty well document and based on old config that i was using for testing, and also my modifed zebda library to help explain, NOTE, ths is only for concept, as it is currently not working (although very close). MUST REMEMBER TO INCLUDE PROTOTYPE IF USING ZEBDA OR REFVWP.

fillin

TO DO

  • disucss combining fillin and clientvalidation into a single filter - sfProcessFormsFilter
  • discuss renaming validate.yml to parameter.yml, as this file IMHO should be handling validation, screeening, fillin and filtering of parameters
  • discuss limitations of fillin, ability to fillin from request, then from flash, then from user attributes (useful for redirected errors and form wizards), added with a lifetime fillin setting in validate(or parameter).yml, which will have the options request, flash and session. When the action is validated, the parameter is automatically stored depedning on the lifetime (auto added to the user session or flash) and updated depending on the lifetime of the parameters upon every request to that action. Fillin will then search these places specific to the form name. EVERY form must be given a name to use, not hard, and probably good practice. Fillin will then work on every request for every form on every page, depending on settings in the forms destination module/action validate(parameter).yml!!!!!! The following example may help explain the new config file better:
screening:
  activate: on
  onsubmit: alert
  onchange: off

fillin:
  activate: on
  name:     form_name
  lifetime: session

methods:
  post:   [x,y,z]
  get:    [x]

names:
  x:
    required:  yes
    required_msg:  required msg
    validators:  myXValdiator, anotherValidator
    converters:  htmlentities, anotherConvertor
    filters:     strip_tags, trim, lowercase

validators:
 myXvalidator:
   ...
 anotherValidator:
   ...

converters:
 htmlentities:
   ...

filters:
 strip_tags:
   ...

NOTE: not that much declaration is required for strip_tags etc but just added for clarity

  • to discuss, providing reduced validators to single validations such as min, max, alphanumeric, numeric, nospecialchar etc

Attachments