Hello @yceruto
Interesting feature, may i ask you if such component can be used to leverage thing like this
#47184
thank you

@94noni In principle, yes, but not by default for every service. It would require a middleware layer to hook into it before the method is called. Currently, only proxies can do that for services. Somehow, collect the class/method decorators for each service and call them from within? but not sure about performance though.

✅ Added Framework integration and controller decoration support

✅ As well as a new Doctrine transaction decorator through #[Transactional] attribute. This decorator can easily help decouple the business logic layer from the infrastructure/persistence layer in any layered-arch app. For example, using the collection-oriented Repository pattern, we can write an API endpoint like this one:

#[Route('/tasks', methods: 'POST')]
class CreateTaskController
{
    public function __construct(private TaskRepositoryInterface $repository)
    {
    }

    #[Serialize(format: 'json')]
    #[Transactional]
    public function __invoke(#[MapRequestPayload] TaskPayload $payload): Task
    {
        $task = new Task($payload->description, $payload->dueDate);

        $this->repository->add($task); // $this->entityManager->persist($task);

        return $task;
    }
}

Keeping the controller code free of persistence and presentation deps. The #[Serialize] decorator can be used as a Serializer (food for another PR), which serializes the result of the given function according to the request format.

This is just an example. There are more approaches and architectures where decorators can be useful.

I updated the PR description to include the Pros and Cons

Interesting! If I understand correctly, I see another useful decorators like “memoize” to cache the result of a method. Looking forward to seeing more feedback 😉

@ostrolucky I understand that this might be a bit confusing at first, especially since we’re already familiar with a decoration method that addresses this kind of problem. However, this new component and its integration are intentionally designed to solve the decoration need in a different way for two main reasons:

1. Support for multiple and nested decorators: this approach allows for several decorators to be applied and even nested, providing greater flexibility in how we handle decorations.
2. Reusability and decoupling: by decoupling the decorator from the targeted method, we enhance reusability. Decorators no longer need to be aware of any specific class or method signature, making them more versatile.

In other words, instead of decorating the service using inheritance (as we used to do by making the decorator aware of the target class and methods), this decoration method targets any callable. This means that multiple decorators can be applied to any callable, and these decorators can be reused without needing to know the details of the classes or methods they’re decorating.

Of course, this approach is best suited for situations where this kind of decoration is beneficial, such as in handlers or controllers.

I (at least I think so) like this! 🤩
However, I do think I might get a fatigue of repeating the same decorators.

#[CollectCacheTags]
#[Serialize(format: 'json')]
#[Validate]
public function __invoke(#[MapRequestPayload] TaskPayload $payload): Task

Is there a way to combine these three to eg #[JsonRequest], or should I go "back" to using regular decorators? The use-case above is a bad example, but hopefully my question makes sense. Or would a (future) improvement be to have "compound" decorators like we have for constraints?

@RobinHoutevelts great idea! It’s definitely possible to add such a nice feature. In the meantime, I’m backporting it into yceruto/decorator-bundle with support for Compound decorators already ;) thanks!

I think this could be useful to integrate locking.

But if the key is dynamic would it be possible to use something similar like with #[IsGranted(PostVoter::DELETE, subject: new Expression('args["postId"]'))] where you can pass arguments to build the lock key?

I think this could be useful to integrate locking.

But if the key is dynamic would it be possible to use something similar like with #[IsGranted(PostVoter::DELETE, subject: new Expression('args["postId"]'))] where you can pass arguments to build the lock key?

It's possible because you have control over the controller's arguments during the decoration phase. At this point, all arguments are already resolved, and their values are the same as what you'll receive in the controller method. However, it's harder to manipulate the arguments since they are just a simple list of values at this stage (not named arguments).

I think that for use cases where you want to add logic based on the controller’s arguments, using a ControllerArgumentsEvent listener is a better and simpler option.

I'd say that a Callable Decorator is a more generic & versatile solution for prepending or appending logic around controllers or any other callable, allowing you to combine decorators or reuse them for different callables. The Transactional decorator is one of the best examples, but I can see many other like caching responses, serializing results, rate limiting, error handling, etc.

I added the Messenger/handler integration since the changes are minimal. Here's what this feature allows you to do:

namespace App\Handler;

use Symfony\Bridge\Doctrine\Decorator\Transactional;

#[AsMessageHandler]
class ProductCreatedEventHandler
{
    #[Transactional]
    public function __invoke(ProductCreatedEvent $event): void
    {
        // update other related data...
    }
}

Similar to controllers, callable decorators are helpful when you need to decorate the implementation of specific handlers. However, if the decorator's logic applies to all handlers on the message bus, it's better to create a middleware instead.

After an internal discussion about the component's name, we decided to rename it to "CallableWrapper". PR and description updated.

I'm closing this for now. I'll revisit this topic soon via an RFC issue with more details on how to implement this feature in a way I believe is better than the one proposed here. Thanks all for your inputs!