-
Notifications
You must be signed in to change notification settings - Fork 50
Improved collector #84
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
Conversation
great work @Nyholm ! how do you display the information? we will end up with a lot of information if several plugins are active... |
Thank you. Im not too sure at the moment to be honest... I'll look at Symfony pages and try to do something similar. |
okay. maybe for each request show the final version that was sent / received by default, and have little tabs to see the other versions between plugins? |
This PR is ready for a review. Im not sure I can make the design look better. |
* | ||
* @return ClientDataProvider | ||
*/ | ||
public function setRequests($requests) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe setters should be removed here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...and the getters... They are not used. Only get*Stack is used.
Not sure if it's possible to add this here, but i would love to have an option to show request and response content as sometime you want to debug the content of the request you send or the response you receive. However this can have memory and latency issue for big request / response (i.e. files), so it would be better to add an option in the config (which default to false) for allowing this feature. WDYT ? |
request and response content? Do you mean the HTTP message body? If so, you can toggle that in the top right corner. Look at image 3. =) |
Who didn't see that, is this an option for the debugger ? And also does it show also the request body ? |
I use the new FullHttpMessageFormatter to capture the full HTTP message for both requests and responses. You may configure the FullHttpMessageFormatter to a different limit on the body. Default is 1000 chars. To change that construction parameter is not supported in this PR. I'll leave that for a future update. |
Just see the formatter and how the request / response is read. As far as i have see, this formatter mess up with the stream, as __toString is called and the stream is not rewind so the content is retrieve only in the first stream ? (I may have miss something again ^^) |
I believe you are correct. I created an issue. So streams should always be rewinded after we read them? |
Depends if the stream is rewindable or not, if not we must buffer the stream into memory and replace it in the request and this will have a huge impact on performance IMO |
Who is using streams that you cant rewind (not seekable) in this case? Guzzle has PumpStream, NoSeekStream, BufferStream and Zend has CallbackStream which never are seekable. I think we should add allow to opt-out of this if there is a major performance impact. |
This looks really cool! Some of those screenshots could be used to illustrate the plugin concept in the documentation :-) regarding streams: i suggest we default to not read anything of the body, but instead have a hint in the debug output that it can be enabled. i would usually expect people to reproduce a call with curl if they want to see the response. (i think we discussed showing a curl command line for a request which would make this trivial - but that is out of scope for this PR) reading the body means messing with streams, which can pose problems or huge slowdowns if there is larger http bodies involved. if its no bid effort, i am ok to keep the option available, but disabled by default. |
That would be a cURL formatter in the message package: php-http/message#19
This is not always possible. In some cases the stream is read-once. We need to provide an alternative stream in that case with the original content. |
i would prefer to wait with merging this until we have a solution to not
break requests with non-rewindable streams.
|
As @Nyholm said copying is not an option, because the request is immutable. So non-rewindable streams should never be read, otherwise users can optionally turn on this feature. |
@@ -68,7 +68,7 @@ public static function createFromCollectedData(array $data) | |||
|
|||
/** | |||
* @param array $messages is an array with keys 'failure', 'request' and 'response' which hold requests for each call to | |||
* sendRequest and for each depth. | |||
* sendRequest and for each depth |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this is a solution. Normally we need that period. See php-http/message#48
@Nyholm it seems symfony changed their CS: symfony/symfony#19198 However, the fixer still seems to be buggy, so I would stick with the full stop everywhere and change it later if necessary. I updated the master branch with the latest styleci config. |
So, No more CS changes in this PR? Since the merge of php-http/message#47 is there anything left to be done in this PR? |
UX: Request 0 -> Request #0 Looks better IMHO, WDYT? |
Sure |
@@ -0,0 +1,132 @@ | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why leading newlines?
As always, I am the style guy 😉 Can you please take a look at my comments? I would leave the technical review to @dbu and @joelwurtz as I haven't really followed this conversation. |
Can you rebase from master? |
6cfe83f
to
97f7943
Compare
This PR is now rebased and I've addressed all your comments except for the one with the Javascript indentation. |
So is this ready for merging then? |
If @joelwurtz and/or @dbu says it is okey, then it's ready to merge IMHO. |
Ok |
@@ -16,11 +16,12 @@ | |||
* @param Plugin[] $plugins | |||
* @param ClientFactory $factory | |||
* @param array $config | |||
* @param array $pluginClientOptions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add a short text that explains the $config and $pluginClientOptions? as its two sets of options, it would help to know what each is to keep them cleanly separated. saying that $pluginClientOptions is forwareded to PluginClient is good enough for me.
looks good. mark had some comments about missing |
I believe I already have addressed Marks comments about |
e7b5002
to
201bcb6
Compare
201bcb6
to
3bcdf1d
Compare
Rebased and ready for being merged |
great job, thanks! |
Thank you all for the reviews and feedback. |
Great job as always @Nyholm. Many thanks. |
This PR is work in progress. I just want to show the progress. Please try it out and give me feedback. I believe the collector and extensions work properly. The work that is left is on the design and display of things.
Related to #26
TODO