On Thu, Jan 11, 2018 at 11:19 AM, Alessandro Lai
<
alessand...@gmail.com> wrote:
> I agree that a PSR standard about the console is a must. I do not agree that
> that PSR should try to bridge between a console app and a normal HTTP app,
> it's too different.
As somebody who has attempted this in the past, I can only concur.
We went this route for ZF2, and created abstract "message" interfaces
for both requests and responses, and then had our HTTP and console
components implement those.
The problem is that you cannot re-use the same message handling logic
between the different message types.
HTTP requests need to pull headers (something unavailable to console
requests), query string arguments (potentially related to the CLI
invocation aguments, but not necessarily), the request method (no
analogue in console requests), and request body (analogue is stdin in
the CLI). Between these sources, and the fact that our route results
were in a completely separate object (and _that_ object was strongly
typed), if the incoming request was a console request, you typically
needed to just bail with an error. In terms of generating a response,
the artifacts are also different: the status you generate for an HTTP
response will be quite different than a console response, and console
responses do not have headers.
For console requests, you would be looking at the CLI arguments,
potentially STDIN, and potentially asking for more input from the
user. This latter has no analogue whatsoever with HTTP, which means
that the code needs to bail early if it determines an HTTP request is
in play.
On top of this, HTTP requests generally return HTML, XML, or JSON,
while console requests return plain text. As a result, the view layer
will vary greatly between the two contexts.
This ultimately led to developers segregating console actions from
HTTP actions within their controllers, and introducing checks in each
action to verify the request type, or different controller types based
on context (so that HTTP controllers can bail early if a console
request is detected and vice versa).
And, down the line, most folks found it was just too cumbersome to
handle CLI requests in the same MVC environment. This led us to create
a dedicated console dispatcher (zfcampus/zf-console) and deprecate the
console tooling for our MVC. And, currently, we recommend users use
symfony/console if they have complex or extensive CLI needs.
My point: I have no problem with creating a standard around console
tooling. I _do_ feel any sort of attempt to provide a unified layer
between http and console tooling is ill-advised.
I'd take a look at what symfony/console and composer (which defines
its own interfaces, and is quite robust) are doing with regards to
handling console I/O, and start the abstraction from there. When you
have the start of a specification forming, try and gather a few people
to form an ad hoc working group, and then see about starting the PSR
process.
> Il giorno giovedì 11 gennaio 2018 16:21:35 UTC+1, Majid abdolhosseini ha
> scritto:
>>
>> psr standars are not for competition between php packages and authors,
>> using these standards you can easily use any package in any framework,
>> or you can even develop your php application wthout using any framework
>> and just, use these standards and some packages use these standars
>> even you can develop your own packages which follow psr rules.
>>
>> and also changes in response and request are many in web and console, It
>> can be an abstraction.
>> I think cosole psr is a MUST.
>
> --
> 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+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/180d3e53-7a10-4566-976b-25900f38f14a%40googlegroups.com.
--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/