Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Streaming body parsers foundation #69

Conversation

WyriHaximus
Copy link
Member

@WyriHaximus WyriHaximus commented Sep 27, 2016

Foundation that way for the multipart, form urlencoded, and nobody parser PR's.

  • Factory
  • Factory documentation blocks
  • Parser interface
  • Parser interface documentation blocks
  • Raw body parser
  • Raw body parser documentation blocks
  • Update readme


interface ParserInterface extends EventEmitterInterface
{
public function __construct(Request $request);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have Factory method, so this antipattern __construct don't need to be in interface.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another way of doing this is having a public static factory method that takes a request. But that would just wrap passing the request into the constructor. Let me give it a try to see how it works out, I don't mind either way 😄 .

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the PR, with use a factory method to create parsers

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks much better for me!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the parser implementations are now marked as @internal, i propose to remove create from the interface since this is now just a additional redundant factory method.

@clue
Copy link
Member

clue commented Sep 28, 2016

I guess this could also use some documentation. What is this used for? When should I use this? Is this only used internally (@internal)?

@WyriHaximus
Copy link
Member Author

@clue added documentation on the parser interface and marked certain methods internal

$this->promise = ContentLengthBufferedSink::createPromise(
$request,
$headers['content-length']
)->then([$this, 'finish']);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, this should be done(). Since you're supporting react/promise < ^2.2, i'm not sure if you there should be a method_exists check here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing it to be ^2.2


$this->promise = ContentLengthBufferedSink::createPromise(
$request,
$headers['content-length']
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if there is no (or an invalid)content-length header? I know there is a check in the Factory, but since this class isn't marked as internal, i think there should be an additional check here or in create.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Marked the class internal (just as NoBodyParser) and throwing an exception in case the header is missing. (In case someone ignores the internal tag.) The value of the header is cast to an integer in the sink forcing it to 0 length in case of an invalid value.

WyriHaximus added a commit to WyriHaximus/http that referenced this pull request Oct 25, 2016
* @param Request $request
* @return ParserInterface
*/
public static function create(Request $request);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the parser implementations are now @internal, i think this method can be removed from the interface and the implementations and simple constructor based instantiantion can be used in Factory.

@WyriHaximus WyriHaximus self-assigned this Nov 30, 2016
@WyriHaximus WyriHaximus added this to the v0.5.0 milestone Nov 30, 2016
@WyriHaximus WyriHaximus changed the base branch from master to 0.5 November 30, 2016 20:34
@WyriHaximus WyriHaximus requested a review from clue December 16, 2016 16:40
@WyriHaximus
Copy link
Member Author

Just updated this PR with documentation in the readme and various files

@clue
Copy link
Member

clue commented Dec 21, 2016

I've talked with @WyriHaximus about this suggestion and I think it makes sense to get this in eventually – but not just yet 👍

I think we agree it makes sense to address PSR-7 support (#28) first. This is something I'm currently looking into with @legionth, so stay tuned.. 😎

@andig
Copy link
Contributor

andig commented Jan 10, 2017

@clue I'd put the priorities differently. If the request parser stuff were there, we could already plug phly/react2psr7 in right now. Might not be the most efficient thing but imho better than waiting?

@clue clue modified the milestone: v0.5.0 Feb 14, 2017
@clue clue closed this Feb 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants