On Thu, Jan 11, 2018 at 11:19 AM, Alessandro Lai <[email protected]> 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/180d3e53-7a10-4566-976b-25900f38f14a%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Matthew Weier O'Phinney [email protected] https://mwop.net/ -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myW7Lxtuyh5Wgy0HJ-AYf9yBqsAPnBZQuou2L2%2B_fmQv_w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
