Taking PSR-7 one step further. Maybe a new PSR idea

[Dracony]

I had a long thought about middleware  and PSR-7. I think that it is indeaad a great idea, but what I don't really like is that it is representing the HTTP protocol, so it wouldn't really work for stuff like CLI. That sounds weird I know, but let me explain:

Imagine we have some JSON middleware that processes JSON requests into form data for your controller and then decodes the response back into JSON. What I don't really like is the whole "form data" part, as it seems redundant ( Middleware would have to decode the data from JSON and then instead of actually passing the data would have to encode it again just for compatibility).

What I am thinking is we may have a use for a very abstract set Request interfaces totally decoupled from HTTP, and pass those around instead. Some examples:

interface Request

{

    public function target(); // e.g. route url

}

class StringRequest implements Request

{

    public function __toString(); // could use that to represent raw JSON data

}

class ParameterRequest implements Request

{

    public function getParameter($name); // could use this one to represent form data

}

The job of each middleware would be to process one kind of request, generate a different one and pass it along. So for example a JSON middleware would take a StringRequest as an input and turn it into a parameterRequest which it would pass along. We could also use something akin to current 'Content-Type negotiation' where middleware A would determine which Request to generate to pass to middleware B.

This way simple middlewares could rely on simpler interfaces, and thus be usable also from non-HTTP environments.

Does that sound like a PSR to you?

[Paul M. Jones]

> On Mar 30, 2015, at 08:05, Dracony <draco...@gmail.com> wrote:
>
> Does that sound like a PSR to you?

Here's the answer I always give: Are a lot of the member frameworks already doing something like it? Can you collect those examples and display their commonalities? If you can answer "yes" to those, and show your work, then "yes" it sounds like a possible PSR. Otherwise no.


--
Paul M. Jones
pmjo...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

[Stefano Torresi]

2015-03-30 15:05 GMT+02:00 Dracony <draco...@gmail.com>:

I had a long thought about middleware  and PSR-7. I think that it is indeaad a great idea, but what I don't really like is that it is representing the HTTP protocol, so it wouldn't really work for stuff like CLI. That sounds weird I know,

I'm sorry, but no, I don't think you realize how awkward this sentence is... It's like "hey guys, this scuba diving mask is really great, but I don't really like that it's made for going underwater, so it wouldn't really work for stuff like... beach soccer!". ;)

 

[...]

Does that sound like a PSR to you?

Nope. There are so many things different between HTTP and CLI applications, I don't think coming up with a new standard from one another would end up in anything good.

Relating the two things and reusing concepts like "request" and "uri" are just a convenient afterthought, that some frameworks (e.g. zf2) applied to maintain the same underlying architecture for both use cases; which is perfectly fine, don't get me wrong, but that is really far from being interoperable because it involves a *specific* architecture.

If you want a standard for CLI apps, a more favourable proposal would be a Command standard interface.

[Matthew Weier O'Phinney]

And I would argue it was a poor fit.

The idea was to supposedly allow re-use of a controller in both an
HTTP and a CLI context. What ended up happening is that the request
and response types were essentially incompatible, which ends up with
having completely different logic for marshaling the data from the
request and populating the response. In the end, developers typically
create different controllers for HTTP vs CLI contexts.

Worse: pushing this into the MVC causes a number of disconnects when
learning; it's difficult to remember where to define CLI rules, error
messages, and help messages, and it's also terrifyingly easy to have
conflicts between commands. As a result, a lot of effort has gone to
making the Zend\Console library self-contained, and some of us even
extended that to create a standalone Console application library
(zfcampus/zf-console) to simplify creation of console applications.

My point: the idea seems good at first blush, until you start
incorporating the ideas into larger applications.

> If you want a standard for CLI apps, a more favourable proposal would be a
> Command standard interface.

Which is why I'd give this a +1, but not the original proposal.

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Roman Tsjupa]

I see your point. I'm sure I can figure it out though. As Terminator said, "I'll be back", and hopefully with something to show =)

--
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/59SLMOqWH6g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myX6Vy6NPEr2o0TBW67-Lax%2B2Vd30GxxLUnj5AQosXtTHw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.