-
Notifications
You must be signed in to change notification settings - Fork 50
replace deprecated directive with new one #145
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
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.
Thank you! Just a small issue
@@ -370,7 +370,7 @@ private function addSharedPluginNodes(ArrayNodeDefinition $pluginNode, $disableA | |||
->addDefaultsIfNotSet() | |||
->children() | |||
->scalarNode('default_ttl')->defaultNull()->end() | |||
->scalarNode('respect_cache_headers')->defaultTrue()->end() | |||
->arrayNode('respect_response_cache_directives')->defaultNull()->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.
We cannot remove respect_cache_headers
because that would be a BC break.
We should have both in the configuration.
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.
But having both configured triggers a \InvalidArgumentException
: https://github.com/php-http/cache-plugin/blob/master/src/CachePlugin.php#L69-L74
What do you propose? Configure both with 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.
We should use scalarNode('respect_cache_headers')->defaultNull()->end()
. That would be the same as "not using it".
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.
Pushed an amendment. Looks better now?
Looking at the diff now, I feel like the merge didn't go entirely ok. Either that or I need to make some amendments. |
Did I do something wrong? Aren't the diff as you intended now? |
|
Yes, and it should be |
->variableNode('respect_response_cache_directives') | ||
->validate() | ||
->always(function ($v) { | ||
if (is_null($v) || is_array($v)) { |
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.
if it must always be an array, use prototyped array node rather than a variable node. It will allow better handling of the data.
Rule of thumb: if you start using variableNode
, rethink what you are doing. Most of the time, you should not need it.
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.
Except it can also be null.
you need to convert |
I'll have more time next week at the earliest unfortunately. |
@stof what approach do you suggest? Converting it is not entirely straightforward since the formats are different ( |
@alcohol what are the new configurations corresponding to The other option would be to rely on a BC layer at the library level (which should be here anyway) and only add a validation rule forbidding to configure both the old and the new way at the same time. The deprecation warning would still be trigger asking to change the configuration though. |
Afaik there is a BC layer in the cache plugin (see here). Not sure what would correspond to |
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.
regarding BC of the old respect_cache_headers
i would suggest to just keep doing the same we did before. the BC layer is in the plugin, not in this bundle. the BC the bundle offers is that the old configuration still works.
@@ -44,7 +44,10 @@ | |||
<my_service type="service" service="my_auth_service"/> | |||
</authentication> | |||
<cache cache-pool="my_cache_pool" stream-factory="my_other_stream_factory"> | |||
<config default-ttl="42" respect-cache-headers="false"/> | |||
<config default-ttl="42" respect-cache-headers="false"> | |||
<respect-response-cache-directives>X-Foo</respect-response-cache-directives> |
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.
this is supposed to raise an error: https://github.com/php-http/cache-plugin/blob/b2f15cee4ff46f61f7b90137b41627d17fd57be9/src/CachePlugin.php#L69-L72
we should remove the deprecated configuration option from the test. if you want to be precise, you can add a separate legacy test for it
Ok I am a bit unclear on what it is that I should implement at this point.
.. please give me some direction :-| |
@alcohol if the library has a proper BC layer, here is my suggestion:
Then, make sure both the new and old config styles work fine for different use cases (enabling directives, disabling them, keeping default settings) |
I'm not very familiar with the Symfony Config Definition stuff. Is it possible to specify that a node can have either A or B as a child, but not both? |
You can look at https://github.com/php-http/HttplugBundle/blob/master/DependencyInjection/Configuration.php#L161-L167 for a similar example. |
Eh, I give up. The documentation of this config stuff is quite useless and I just keep getting different errors that provide no clear instructions as to how to fix what is wrong. |
don't give up please. basically its enough to allow the old and the new configuration and trigger a deprecation warning when the old config is used. all the BC handling is done by the library. if the config can complain when both are set, all the bether. otherwise there is an exception on trying to load the service that is thrown by the plugin because it does not want both settings to be set. |
Using
it adds both Using
it throws a cryptic exception that doesn't tell me anything about how to solve this problem (neither does the documentation):
|
|
@stof but that one sets all 3 configured nodes, while I only want to set 2 by default (skip the deprecated one if not provided). |
Well, don't put a default value on the deprecated node if it should not be there by default |
Ok I think I have the error scenario covered. Where should I do the legacy conversion and warning trigger? |
@alcohol don't do the conversion (the library does it). And for the warning trigger, do it in a |
Hmm the problem I run into now is that if the deprecated |
@alcohol I think it is. |
Okay I think that covers it, although I am not sure how to test that it actually triggers the deprecation since it gets silenced. |
Oh FFS. On Travis it fails cause the deprecation is seen. But locally (running same phpunit version) I get nothing like that.
|
Make sure you use the same versions of deps too |
For some reason I did not have the phpunit-bridge installed. Okay, lets see if I can find documentation on how to specify this deprecation as "expected". |
Good lord I wasted far too much time on this today. |
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.
thanks a lot! yeah, this can sometimes be tedious to make things clean and BC and user friendly. but you also learned some things on the configuration i guess ;-)
Not really, I'm still not clear for example on what the difference is between a concrete node and a not-concrete node :-(. There is zero documentation on this subject. |
i squashed the commits, fixed the thing that styleci complained about and merged to master. thanks a lot for your persistence @alcohol and i agree with you, the documentation on the configuration definition is lacking. i tend to look up examples in other bundles i know to figure out how to do things. doctrine is quite useful because they have to do some complicated use cases ;-) |
Thanks, glad I could still contribute something at least :-) |
No description provided.