-
Notifications
You must be signed in to change notification settings - Fork 50
Discovery bugfixes and more flexible. #87
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
@@ -83,6 +83,8 @@ public function getConfigTreeBuilder() | |||
->defaultValue('auto') | |||
->end() | |||
->scalarNode('formatter')->defaultNull()->end() | |||
->booleanNode('inject_debugger_for_discovered_http_client')->defaultTrue()->end() |
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.
I am not sure if we want this opt-in by default.
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 not? All the other clients are opt-in by default.
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.
Correct me if I am wrong, but this will register the default client in the discovery, will it not? If so, all the problems I listed in the previous PR can still occur. I would rather have this as an optional feature stating you can turn this on for discovered clients if you want.
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 we find a shorter name? Like profile_discovered_client
and profile_discovered_async_client
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.
Correct me if I am wrong, but this will register the default client in the discovery, will it not?
No, It will find take a (new) unconfigured client and add toolbar debugging on that and then make sure that this client is found by discovery in the future.
This PR also lets to you decide if you want to use a configured client as auto discovery.
Can we find a shorter name? Like profile_discovered_client and profile_discovered_async_client
Yes please. It was quite late last night when I wrote this. =)
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.
Okay, so by default a discovered, unconfigured client is simply wrapped with debug tools and put back to discovery and you can also choose to use a configured client for that, but that is optional, opt-out by default?
201bcb6
to
d5e9bcd
Compare
you might need to cherry-pick commits into a new branch as #84 is now squashed. there is a conflict reported by github. |
Yes. I'll make this PR ready for review shortly. |
d0f9be9
to
c380db9
Compare
c380db9
to
d49f7d6
Compare
There. This PR is ready for review. Consider the following config httplug:
toolbar:
profile_discovered_client: true # Default
profile_discovered_async_client: false # Default
classes:
clients:
my_guzzle6:
factory: 'httplug.factory.guzzle6'
acme:
factory: 'httplug.factory.curl' This will create a two new private services: If a user want to control what client is found by auto discovery he/she may add httplug:
toolbar:
profile_discovered_client: false # Does not matter when 'use_with_discovery'
profile_discovered_async_client: false # Default
classes:
clients:
my_guzzle6:
factory: 'httplug.factory.guzzle6'
acme:
factory: 'httplug.factory.curl'
use_with_discovery: 'http_client' |
What does this mean? Neither the key nor the value is obvious IMO. |
You can choose what client to be found by HttpClientDiscovery::find and HttpAsyncDiscovery::find. I added a comment about it here: https://github.com/php-http/HttplugBundle/pull/87/files#diff-850942b3ba24ab03a40aaa81b6152852R129 But maybe that was not the best one |
What if someone wants one client to be used as both? Is there a type check to make sure the chosen client is actually of the relevant type? What if this is configured for multiple clients? |
Correct. That was missing
Yes, In the discovery strategies contstuctor
Then an exception will be thrown |
Then maybe we could have the following configuration: httplug:
discovery:
client: client_id # optional
async_client: async_client_id # optional
profile_client: true
profile_async_client: false |
I like it! |
Since httplug:
discovery:
client: 'auto' # could also be a service name like 'httplug.client.acme'
async_client: 'none' # default But this does not however tell you about the profiling... Is there a better config? |
When there is a concrete client configured, profiling is enabled for it automatically? |
Yes |
Then I am fine with that. Although probably we should have null (~) values by default and those should be mapped to auto and none. WDYT? |
This PR is now ready for review |
->info('Set to "auto" to see auto discovered client in the web profiler. If provided a service id for a client then this client will be found by auto discovery.') | ||
->end() | ||
->scalarNode('async_client') | ||
->defaultNull() |
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 not auto as well?
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.
Because if no AsyncClient is found we get an exception. I do not think I can catch that.
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.
okay. but then lets change the info to mention that you should set this to auto if you know that you have an async client available.
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.
Or should I put that in the docs?
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.
i have one question and one suggestion. but overall, this looks good, i like it. please also start with the documentation as soon as we are set on how this works, so that we don't forget the details of auto vs null and so on... |
Can we merge this and tag v1.2? |
} | ||
|
||
/** | ||
* {@inheritdoc} | ||
*/ | ||
public static function getCandidates($type) | ||
{ | ||
if (static::$client !== null && $type == HttpClient::class) { | ||
if (static::$client !== null && $type === HttpClient::class) { |
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.
Should the type check rather come first? This way the first condition is evaluated even if the type is a MessageFactory.
What's in this PR?
With this PR I wanted to achieve two things: