Sure — here’s an example.
Let’s say you have a UploadBlogPost and a ViewBlogPost request. Let’s say the
UploadBlogPost request takes an unique id and the post’s body and sticks it
into a database. And let’s say ViewBlogPost takes an id, and returns the blog
post associated with that id.
The UploadBlogPost request shouldn’t be sent in by just anybody. And what if
the unique id isn’t so unique after all? So we write up, let’s say, an
AuthenticatedRequest decorator and a TransactionalRequest decorator. The
ViewBlogPost request, however, can be sent in by anybody, and it is read-only,
so it doesn’t have to be transactional, either.
So for UploadBlogPost, you’d have the dependency injection container return a
new AuthenticatedRequest(new TransactionalRequest(new UploadBlogPostHandler)));
and new ViewBlogPost(); respectively. That’s what I meant by fine-tuned — you
do not want none of that if ( $request instanceof UploadBlogPost) { … } else if
( $request instanceof ViewBlogPost ) { … } nastiness.
On the other hand, we want to log all requests that comes in, right? And what
if that AuthenticatedRequest decorator throws an UserNotAuthenticatedException?
We’d want to handle that before that thing bubbles up beyond the router, right?
So those are things that apply to the application in its entirety — no matter
what request comes in, we’ll always need those middlewares ready for action.
That’s where PSR-15 may make more sense. Let’s say we have this in the
index.php file — a simplified example, not necessarily correctly implementing
PSR-15, but you get the idea:
$stack = new Stack();
$stack->add(function ($request, $response) { */ does the logging goodness */});
$stack->add(function ($request, $response) { */ sends the request off to its
handler. If the handler doesn’t like it, catch the exception and… */ });
$stack->add(function ($request, $response) { */ … send it to here, where the
exception is handled. */ });
It wouldn’t make sense for a framework to provide fine-tuned middleware
support, but a ‘one-size-fits-all’ middleware inter-op does make sense. PSR-15
allows a framework to “run” any middleware you may build without a mess of
if-else statements.
The above example is probably not how I’d write it ‘in the real world’, but I
hope you get the idea of what I’m trying to say :)
John
On Apr 21, 2017, at 1:41 PM, Rasmus Schultz
<ras...@mindplay.dk<mailto:ras...@mindplay.dk>> wrote:
I'm not sure what you mean by "fine-grained" middleware?
This "fine-grained" middleware performs request-to-response processing the same
as "general" middleware - they have the same method signature.
This is pretty abstract, so can you support this point of view with
code-samples or scenario/use-case descriptions to illustrate?
On Fri, Apr 21, 2017 at 7:07 PM, Rivera, John
<rive...@buffalo.edu<mailto:rive...@buffalo.edu>> wrote:
This is exactly how I handle most of my middleware as well — I have a project
that uses the CQRS architectural pattern, and I decorate each command handler
using this exact pattern.
I build the dependency graph in my dependency injection container, and use a
mediator to dispatch commands to their (decorated) handlers.
This is excellent for fine-tuned control over specific command handlers and
their aspects.
However, I can see a use for the PSR-15 style middleware — I see two different
kinds of middleware: fine-grained middleware (some requests needs to be
authenticated, some needs to be within a database transaction, maybe one or two
requests result in an event that you need to fire off, etc), and the general
middleware (you want to log all requests, you want to catch any exceptions and
handle them appropriately, etc).
I think the approach we are discussing here is ideal for fine-grained
middleware — it makes the dependency graph explicit and easy to configure and
maintain separately. PSR-15 is ideal for general middleware, which you can take
a more functional approach to — there would (or should) only be a few layers,
and they would apply to the application as a whole.
Just my two cents.
John
On Apr 21, 2017, at 12:40 PM, Beau Simensen
<simen...@gmail.com<mailto:simen...@gmail.com>> wrote:
On Friday, April 21, 2017 at 10:42:11 AM UTC-5, Rasmus Schultz wrote:
$kernel = new NotFoundMiddleware();
$kernel = new RouterMiddleware(new Router(...), $kernel);
$kernel = new CacheMiddleware($kernel);
$kernel = new ErrorHandlerMiddleware();
Off the top of my head, it feels like this would be difficult to automatically
wire with a DI container since each middleware will need to be constructed with
the previous middleware already instantiated. Especially given you cannot have
consistent known arguments, this will be difficult to automate.
return $this->container->get($id)->process($request);
I think you tried to address this with the ContainerProxyMiddleware but it
skips the construction part. How would the container know which $kernel to use
in the constructor for the object at $id? This looks nice, API-wise, but it is
ignoring how this object would actually be constructed.
One of the things we did with Stack was required the first argument to always
be the kernel and any additional arguments (if any at all) would have to follow
after that. We used Stack Builder to help try and solve those problems. It
still seemed messy and I was never very happy with it.
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
php-fig+unsubscr...@googlegroups.com<mailto:php-fig+unsubscr...@googlegroups.com>.
To post to this group, send email to
php-fig@googlegroups.com<mailto:php-fig@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/99e602d1-e871-4d19-829a-1330252b508c%40googlegroups.com<https://groups.google.com/d/msgid/php-fig/99e602d1-e871-4d19-829a-1330252b508c%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/php-fig/B3jtdJA7-6w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
php-fig+unsubscr...@googlegroups.com<mailto:php-fig+unsubscr...@googlegroups.com>.
To post to this group, send email to
php-fig@googlegroups.com<mailto:php-fig@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/57FC4BBE-38F8-4B7D-B02D-1E003A0B7D21%40buffalo.edu<https://groups.google.com/d/msgid/php-fig/57FC4BBE-38F8-4B7D-B02D-1E003A0B7D21%40buffalo.edu?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
php-fig+unsubscr...@googlegroups.com<mailto:php-fig+unsubscr...@googlegroups.com>.
To post to this group, send email to
php-fig@googlegroups.com<mailto:php-fig@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CADqTB_imT06jv9v-3DN4_uv1vZmmqO%2B6at8Ny5DpocWNNPmZCg%40mail.gmail.com<https://groups.google.com/d/msgid/php-fig/CADqTB_imT06jv9v-3DN4_uv1vZmmqO%2B6at8Ny5DpocWNNPmZCg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/88F5DE6C-20F1-4CCF-A84C-655FA32AC471%40buffalo.edu.
For more options, visit https://groups.google.com/d/optout.
