phpgt/domvalidation

Server side form validation using web standards.

domvalidation's Issues

Documentation

The wiki needs filling for launch of www.php.gt

Differentiate error message for select/radio

Missing values should show:

• "Please select an item in the list" for select elements.
• "Please select one of these options" for radio elements.

Matrix builds & QA tools

Introduce matrix builds with phpmd and phpcs.

Allow any iterable, so no casting is required

Currently the validate function only accepts an array.

Client side dynamic select options

It is common to add elements to a on the client, in which case the server-side validation will not work for select elements, because the options are not within the original HTML. This will require disabling SSV for particular elements, or using custom rules.

Use title attribute to provide custom error text

This is implemented in browsers according to https://www.w3.org/TR/html51/sec-forms.html#the-pattern-attribute (example 25).

The title attribute can provide a custom description of a valid input, such as "Credit card numbers must be 16 numbers". Then, rather than an error text being simply "This field does not match the required pattern", it can be concatenated with the title, such as "This field does not match the required pattern: Credit card numbers must be 16 numbers".

Dependabot

Dependabot needs to be tamed, as per PhpGt/WebEngine#568

Expose the type of error that occurs

From MDN:

badInput, patternMismatch, rangeOverflow or rangeUnderflow, stepMismatch, tooLong or tooShort, typeMismatch, valueMissing, or a customError.

Custom validation rules

A valuable feature would be to use the same functionality exposed by this repository, but on the developer's own application logic.

Not just field contents, but complex logic according to records in the database, or other logic constraints.

minlength, maxlength for all inputs

This should apply to all inputs, not just text/search/url/password/etc.

Compatibility with PHP.Gt/Dom's new Facade

Checkboxes should not be able to send invalid data

If there are three checkboxes with values "1", "2" and "3", the user agent should not be able to send a value of "X".

How do we identify which form has been submitted?

When a form is submitted through a GET or POST request, the server needs to know which form was submitted, so that when the request comes in, the server can validate against the set of rules described within the <form> element itself.

The first idea was to handle this automatically, without any developer input. The functionality could check the user input parameters against all forms in the document and validate against a match. However this is error prone, as the user input may be manipulated by the user.

Proposed solution:

A Validation class can be instantiated with context of the <form> in question. Exceptions will be thrown by the constructor if there are validation errors which can be caught and iterated over.

Example code:

function doSave(InputData $data) {
	try {
		new Validator($this->document->getElementById("example-form"));
	}
	catch(ValidationException $exception) {
		foreach($exception->invalidElementList as $element) {
			$element->classList->add("invalid-required");
			$element->dataset->error = $exception->getMessage();
		}
	}

	completeSaveAction();
}

The above solution provides the developer complete control over the whole validation mechanism.

Validation types

The standard client-side validation types will be respected:

• required - field can not be left blank
• pattern="\d\d-\d\d-\d\d - must match a provided pattern
• type="email" - must match a predefined type of data, such as email, tel, number, etc.

Valid types:

https://www.w3.org/TR/html51/sec-forms.html#sec-states-of-the-type-attribute

• tel
• url
• email
• date (min, max)
• month (min, max)
• week (min, max)
• time (min, max)
• datetime-local (min, max)
• number
• range (min, max)

Common attributes that should be respected:

• minlength
• maxlength
• step

Tidy up for v1 release

This repository will be included in the upcoming stable WebEngine release and needs a bit of maintenance.

Should we act as a user agent and fix bad inputs?

From https://www.w3.org/TR/html51/sec-forms.html#number-state-typenumber :

This specification does not define what user interface user agents are to use; user agent vendors are encouraged to consider what would best serve their users' needs. For example, a user agent in Persian or Arabic markets might support Persian and Arabic numeric input (converting it to the format required for submission as described above). Similarly, a user agent designed for the French market might display the value with apostrophes between thousands and commas before the decimals, and allow the user to enter a value in that manner, internally converting it to the submission format described above.

Should a number input value of 12'345'678,90 be valid after being converted to 12,345,678.90 and subsequently the floating point number of 12345678.9?

Radio buttons to behave similar to select elements

Select elements must match a valid value of a contained option element. This is similar to type-radio.

Document ajax validation

A common pattern is to submit the form with a fetch request, but append an extra field to only do the validation - then the form can be updated live without having to submit the entire form each time.

type=number - validate "step" attribute

An input with type=number is valid for any type of number - negative, floating point, etc.

A step attribute indicates the valid resolution of the number. To force integers, step=1 is used, so the valid numbers increase by 1.

It can also be used to set the resolution of an input field. For example, step=0.1 means that anything with a resolution of one decimal place is valid, for example 12.3, but something with more resolution is not, for example 12.34.

Select option validation

A <select> element should only be able to submit the <option> values it enumerates Other values should be seen as invalid.

Replace Scrutinizer

It takes WAY too long to execute the tests, and isn't managed as part of Github Actions, so it should be put to rest.

Github actions