Closed sagikazarmark closed 9 years ago
Also, your wishes came true: it only processes commands which also implements the appropriate message interface (others are passed to the next middleware). To make this easier I introduced a QueueableCommand
interface which extends the Command
and Message
interfaces. I also removed the CommandProxy
as it was never a real proxy.
However I think it is a problem that currently ONLY those commands can be queued which are designed to be sent through queues. I think it is a problem, it should rather be transparent or switchable somehow. So I am thinking about a real proxy solution.
I noticed, hooray! I can understand wanting it to be customizable though. What about a separate interface for that? QueuingDecision or something like that.
That's what QueueableCommand interface is for. However I think that commands itself should be separated from the middleware it handles. In other words: it feels weird to explicitly say this command MUST run in a QueueMiddleware (if available). But I will probably leave it to another PR/issue.
Have to read more closely but I like where it's going. :grinning: