Console Psr

[Majid abdolhosseini]

Hi,
I think an application is bunch of logic and data manipulation ( R/W )

every application (in my opinion everything in the world) has an input do sth on that input and create an output.
how application triggers (application input ) shouldn't affect how application execute and what happens in it.

so for php applications input is mostly console or web, for http request (web) we have psr if we could have a psr for console
we could write adapter to get input from both console and web,
so we didn't need to separate our application in console and http (like frameworks do now).
so console psr is necessary.

[Alexander Makarov]

Console is a bit different. It may have additional inputs in the middle of processing and that's usually the case.

[Majid abdolhosseini]

It depends on how you see things.
If you make abstraction, it's possible,

just consider there is a software (application) which takes some inputs and return output.
when developing application I don't care how I get inputs (console or web or ...).

I don't care additional inputs are given to process in the middle of processing or at the beginning of process, the important thing is the interface for cli commands, and time is not important when it comes to programming into interface.

[Alessandro Lai]

Time may not be important, but the fact that there is a challenge and response between the user and the application may change a lot the type of interaction. I hardly see a way to standardize this kind of stuff between a console and an HTTP part of an app.

[Woody Gilk]

In terms of HTTP input, PSR-7 does a fantastic job of providing a
standard interface to access input parameters.

As for console input, one of the benefits is that during the execution
of the console application it can ask for additional input. Asking a
user for a password, rather than using it as an input parameter in
plain sight (and console history!) is one obvious benefit of this
interactive input. Composer makes great use of this to ask for
required input that is not passed when initially invoked.

That being said, I think that Symfony's Console component is the
de-facto standard for console applications, including input and
output. I would be trilled to see someone create a PSR that abstracts
those interfaces to allow for more competition in the console space.
While symfony/console is easy to use, it is rather large and somewhat
awkward to use outside of Symfony, particularly when it comes to
dependency injection.
--
Woody Gilk
http://about.me/shadowhand

> --
> 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/39f8fe32-5242-40e2-876c-65d3d03594ed%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Majid abdolhosseini]

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.

[Alessandro Lai]

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.

[Matthew Weier O'Phinney]

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.

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

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

[Larry Garfield]

On Thursday, January 11, 2018 11:56:48 AM CST Matthew Weier O'Phinney wrote:

> 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.

*puts on CC member hat*

I fully agree with the above position.

--Larry Garfield

[Majid abdolhosseini]

I really don't insist on an abstraction between console and web applications, I'll think more about it,

but as I said , creating a psr for console commands is a MUST,
and as all you agree, console psr is going to be created, and I'll be happy if I could help.

[Mark Railton]

I agree that a PSR for console commands would be a major benefit.

Mark Railton

Sent from my iPhone

--

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/1f5488f3-1983-46fd-9750-0907f35419c3%40googlegroups.com.