* 4.2:
[Routing] Fixed unexpected 404 NoConfigurationException
[DI] Removes number of elements information in debug mode
[Contracts] Simplify implementation declarations
Update PR template for 4.3
[Intl] Add FallbackTrait for data generation
[Console] Commands with an alias should not be recognized as ambiguous
clarify the possible class/interface of the cache
This PR was merged into the 4.3-dev branch.
Discussion
----------
[Contracts][EventDispatcher] add EventDispatcherInterface to symfony/contracts and use it where possible
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This PR adds a new `EventDispatcherInterface` in `Contracts`. This interface contains only one method: `dispatch($event, $eventName)`. That covers almost all use cases of the event dispatcher in components (some use add/removeListeners/Subscribers but they are a minority.)
While doing so, it allows dispatching any objects as events - not only instances of `Event`.
This allows decoupling e.g. `Messenger` from the `EventDispatcher` component.
Next steps could be about planning to remove the base `Event` class from some concrete event classes and/or moving `EventSubscriberInterface` to `symfony/contracts`. It would allow decoupling e.g. `Workflow` from the component - but that's too far away for now, let's think about it in 5.1.
Commits
-------
3c3db2f14a [Contracts][EventDispatcher] add EventDispatcherInterface to symfony/contracts and use it where possible
This PR was merged into the 4.3-dev branch.
Discussion
----------
[HttpClient] add MockHttpClient
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This PR introduces `MockHttpClient` and `MockResponse`, to be used for testing classes that need an HTTP client without making actual HTTP requests.
`MockHttpClient` is configured via its constructor: you provide it either with an iterable or a callable, and these will be used to provide responses as the consumer requests them.
Example:
```php
$responses = [
new MockResponse($body1, $info1),
new MockResponse($body2, $info2),
];
$client = new MockHttpClient($responses);
$response1 = $client->request(...); // created from $responses[0]
$response2 = $client->request(...); // created from $responses[1]
```
Or alternatively:
```php
$callback = function ($method, $url, $options) {
return new MockResponse(...);
};
$client = new MockHttpClient($callback);
$response = $client->request(...); // calls $callback internal
```
The responses provided to the client don't have to be instances of `MockResponse` - any `ResponseInterface` works (e.g. `$this->getMockBuilder(ResponseInterface::class)->getMock()`).
Using `MockResponse` allows simulating chunked responses and timeouts:
```php
$body = function () {
yield 'hello';
yield ''; // the empty string is turned into a timeout so that they are easy to test
yield 'world';
};
$mockResponse = new Mockresponse($body);
```
Last but not least, the implementation simulates the full lifecycle of a properly behaving `HttpClientInterface` contracts implementation: error handling, progress function, etc. This is "proved" by `MockHttpClientTest`, who implements and passes the reference test suite in `HttpClientTestCase`.
Commits
-------
8fd7584158 [HttpClient] add MockHttpClient
This PR was merged into the 4.3-dev branch.
Discussion
----------
[HttpClient] add ResponseInterface::toArray()
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
I'd like we discuss adding a `toArray()` method to `ResponseInterface`.
JSON responses are so common when doing server-side requests that this may help remove boilerplate - especially the logic dealing with errors.
WDYT?
(about flags, I don't think we should make them configurable: if one really needs to deal with custom flags, there's always `ResponseInterface::getContent()` - but it should be very rare.).
Commits
-------
aabd1d455e [HttpClient] add ResponseInterface::toArray()
* 4.1:
[Form] Hardened test suite for empty data
Bump phpunit XSD version to 5.2
[Fwb][EventDispatcher][HttpKernel] Fix getClosureScopeClass usage to describe callables
Add required key attribute
This PR was merged into the 4.2-dev branch.
Discussion
----------
[Cache] add CacheInterface::delete() + improve CacheTrait
| Q | A
| ------------- | ---
| Branch? | 4.2
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
I've been hesitating a lot on this topic, but I think we should add a `delete()` method to `CacheInterface`.
Deleting is a very common invalidation strategy and invalidating by passing `$beta=INF` to `get()` has the drawback of requiring a fetch+unserialize+save-with-past-expiration. That's complexity that a delete removes.
This PR fixes an issue found meanwhile on `get()`: passing an `ItemInterface` to its callback makes it harder than required to implement on top of PSR-6. Let's pass a `CacheItemInterface`.
Lastly, the early expiration logic can be moved from the component to the trait shipped on contracts.
Here we are for all these steps.
Commits
-------
c6cf690b2f [Cache] add CacheInterface::delete() + improve CacheTrait
FrameworkBundle 4.2 will be compatible with older versions of the Cache
component. In those versions adapters don't implement `ResetInterface`.
For backwards compatibility they still need to be tagged.
