laminas/laminas-validator

Validator result interface proposal

michalbundyra opened this issue · 7 comments

michalbundyra commented

This is a proposal of ResultInterface about the stateless validator proposal made in:

/cc @bakura10 @zendframework/community-review-team

Originally posted by @Maks3w at zendframework/zend-validator#24

michalbundyra commented

I agree with @manuakasam , this is highly confusing. Usage in my PR is much easier. People should not having to deal with two different objects for retrieving messages error. The workflow should staty like this:

$result = $validator->validate('foo');

if (!$result->isValid()) {
   foreach ($result->getMessages() as $message) {
      echo $message;
   }
}

This is the typical and most common use case. Translation should only be used for people that needs it. I really don't like this proposal :(.

Originally posted by @bakura10 at zendframework/zend-validator#24 (comment)

michalbundyra commented

Also, I'm not sure what you are trying to do here. Trying to integrate the validation result stuff into the 2.x branch? This is a BC, all the validators are not stateless, you are going to go through a lot of pain and hazardous process if you try to make this BC with current architecture.

Also, there are other things I'd like to refactor in the validators themselves to make them more coherent with ZF conventions, so I'd prefer to do all the BC at once.

Originally posted by @bakura10 at zendframework/zend-validator#24 (comment)

michalbundyra commented

Also please have a look at my own implementation for different way to solve the same issue bakura10/zend-validator#1

Originally posted by @bakura10 at zendframework/zend-validator#24 (comment)

michalbundyra commented

I like the idea of @weierophinney about to use a helper function for to translate the message

I would like to extend de concept of translate to not only an optional feature for HumanLanguageA <=> HumanLanguageB but make it a requirement for do ErrorCode => HumanLanguageX

In such case the translation tool should look for the error code in a message collection and interpolate the message with the validation context and values cardinality

In resume:

  • Message templates associated to a validator (text-domain)
  • Validation error code for choose a single template (translation template)
  • A validation context collection of values for freedom on make contextualized error messages.
  • Each value have a cardinality associated for proper use of plurals, etc.

Originally posted by @Maks3w at zendframework/zend-validator#24 (comment)

michalbundyra commented

For translations, it could make sense to rely on intl's MessageFormatter, as it works much nicer with formatting multiple different variable types in a single message, as opposed to how gettext's plural handling is always based on a single value.

Originally posted by @DASPRiD at zendframework/zend-validator#24 (comment)

michalbundyra commented

Marking as 3.0, as returning a result instance is a BC break from current usage.

Originally posted by @weierophinney at zendframework/zend-validator#24 (comment)

michalbundyra commented

This repository has been moved to laminas/laminas-validator. If you feel that this patch is still relevant, please re-open against that repository, and reference this issue. To re-open, we suggest the following workflow:

  • Squash all commits in your branch (git rebase -i origin/{branch})
  • Make a note of all changed files (`git diff --name-only origin/{branch}...HEAD
  • Run the laminas/laminas-migration tool on the code.
  • Clone laminas/laminas-validator to another directory.
  • Copy the files from the second bullet point to the clone of laminas/laminas-validator.
  • In your clone of laminas/laminas-validator, commit the files, push to your fork, and open the new PR.
    We will be providing tooling via laminas/laminas-migration soon to help automate the process.

Originally posted by @weierophinney at zendframework/zend-validator#24 (comment)