[Validator] Passing Constraints to Object similar to Assert\Collection

[Hanmac]

Description

Discussion from there: #54299

I got some nested Object is want to be validated,
but the Constraints depends on some outside value, so I can't use Attributes on their properties

Using Assert\Collection, I could validate them if they were arrays, but that might not always be the case.
I could use Serializer to normalize the objects, but that might give a different result in their error messages.

So instead, a new Assert\ValidObject (or something) that takes an array of constraints and uses it for validation instead of the Class Metadata.
Should probably use PropertyInfo / PropertyAccess to get from the keys to the real properties?
Or maybe a way to extend the use of Assert\Valid ?

Example

Example Entities:

namespace App\Entity;

class Address
{
    protected string $street;

    protected string $zipCode;
}

class Author
{
    protected string $firstName;

    protected string $lastName;

    protected Address $address;
}

Example:

public function validateAuthor($author, int $maxZip)
{
    // validate via ArrayAccess
    $validator = Validation::createValidator();
    return $validator->validate($author, new Assert\ValidObject([
        'address' => new Assert\ValidObject([
            'zipCode' => new Assert\Length(['max' => $maxZip]) // have a max 
        ])
    ]));
}

[derrabus]

This kind of configuration typically belongs into class metadata. What's the reason why we don't have configured metadata for those classes in your context?

[Hanmac]

This kind of configuration typically belongs into class metadata. What's the reason why we don't have configured metadata for those classes in your context?

Like I said:

depends on some outside value

For example, the max length of some fields in my use case depends on some configuration that is unique for some clients.
These values i would load from the external config, and pass them when the Constraint is created

[derrabus]

This kind of configuration typically belongs into class metadata. What's the reason why we don't have configured metadata for those classes in your context?

Like I said:

depends on some outside value

That does not answer the question for me. So your metadata depends on "some outside value". Why is that a problem?

[Hanmac]

This kind of configuration typically belongs into class metadata. What's the reason why we don't have configured metadata for those classes in your context?

Like I said:

depends on some outside value

That does not answer the question for me. So your metadata depends on "some outside value". Why is that a problem?

Let's say for example I got a Shop system, that on multiple instances of my customers.
On these Shop systems, lists are created, to send Transaction data to an external Service. (that checks if these Transactions are paid)
Now, PER SHOP, it should be able to configure how long some of the fields are.
(If you want to know, one of them is called objektnummer)
Because these limits are flexible, I CAN'T create classes for each shop.
That's why the Limit is configured in the Settings of each shop. (like different Entity Model)
And that is also why my Validation check that I implemented can't read them of the class Metadata.

I don't think it would be a good idea to alter the class Metadata each time the validate function is called?

[derrabus]

Let's say for example I got a Shop system, that on multiple instances of my customers.

What is an "instance" in this context?

I CAN'T create classes for each shop.

I never said you should do that. We just need to make sure, the class metadata can be different for each shop.

I don't think it would be a good idea to alter the class Metadata each time the validate function is called?

I never suggested to do that either.

[Hanmac]

Let's say for example I got a Shop system, that on multiple instances of my customers.

What is an "instance" in this context?

Each of my customers gets their own shop instance (a virtual server) with a Magento Shop System.
The Validator is used in a required lib without Symfony framework.

I CAN'T create classes for each shop.

I never said you should do that. We just need to make sure, the class metadata can be different for each shop.

Theoretically, but I don't see how the Attribute Constraints (the fixed values?) and the dynamic Constraints (the ones that I currently need this feature for) should be mixed.

Especially if I'm outside Symfony framework and can't rely on DI