I like the idea. I often find myself needing a different validation on 1 or more properties based on another value. There's but one problem in your example, getDynamicGroups is static but relies on $this->customerType.

The example is fixed, shrunk an existing class which caused the error :)

@weaverryan or @javiereguiluz Any comment from your side? The would be great for the DX IMHO. I can easily polish this up and get this ready, otherwise I am closing the PR.

I would like to see this implemented with a @DefaultGroup annotation as suggested here: #11880 (comment)

@webmozart I am not totally sold on the @DefaultGroup proposal as in one use case I have an entity with partial validation and I do not see this necessary as releated to a DefaultGroup. I might also be confused with the DefaultGroup name.

/**
 * @DynamicGroups(groupProvider="dynamicGroups", groups="case1")
 * @DynamicGroups(groupProvider="otherDynamicGroups", groups="case2")
 */
class Customer
{
    /**
     * @Assert\NotBlank()
     */
    private $customerType; // Customer or Person

    /**
     * @Assert\NotBlank(groups={"Company"})
     */
    private $companyName;

    /**
     * @Assert\NotBlank(groups={"Person"})
     */
    private $lastName;

    public function getDynamicGroups()
    {
        return [$this->customerType];
    }

   //...
}

@webmozart Any further comment?

@webmozart How about continuing with this way and deprecating it once there is a better way. I think it would be good to have such functionality in core. If not we should just close the PR.

Looks like such solution is not wanted. Closing due to lack of feedback.

@peterrehm To me it sounds like you need a better data model. Having one class that stores all fields and data for different representations of a "thing" smells. Without knowing more details, I would try to extract fields of your Customer in interfaces like CustomerData (implemented by CompanyData and PersonData), PaymentDetails (implemented by CreditCard and BankAccount) etc. Those can contain there specific validation rules, (hopefully) rendering the need for dynamic groups obsolete.

@webmozart I expect there are common use cases for my sample. Of course you can try to abstract small things like your mentioned CompanyData or PersonData, I think for simple cases it makes things more complex.

@peterrehm I guess the question is how you define "complex". I think dynamic validation groups are quite complex to understand.