add ResolverInterface::isStored

[havvg]

see liip#284

[makasim]

@havvg do we really need such methods in the manager?

<?php
$cacheManager->getResolver($filter)->isStored($path, $filter);

Maybe something like this would be better. I am just wonder.

[havvg]

I just added this method because the other forwards are also present.

[makasim]

we can back to this later. good for now.

[makasim]

I think we should throw an exception when resolve method is called before store one. I can do it after merging your. Just confirm you think we should have an exception.

[havvg]

What do you mean by "when resolve method is called before store", why is that an exceptional state/process?

[makasim]

let's assume one tries to execute next code

<?php

$cacheManager->isStored($path, $filter);
//false

//and now I am trying to call resolve
$cacheManager->resolve($path, $filter);

//what should it return? I propse to throw exception in this case

[havvg]

The resolve method is only responsible for returning an URL to read the image from. The only case I can see, where such an exception is valid, would be a resolver which needs to connect to a datasource to ask for the respective URL where the path is the identifier.

However by design there is no need for this. I'm fine with adding an exception class to be thrown, so one exists within the namespace and we can handle those. The bundled resolver are fine as they are. They are capable of resolving to the target url, even if there actually might be no image available.

[makasim]

yeah the bundle itself would never throw this exception. Because we use the logic in the right order isStored if not store and then resolve. But let's assume one implement its own logic and somehow called resole before actually storing something to cache. The exception is needed I think

[havvg]

The exception itself is fine and should be provided by the bundle. But no resolver of this bundle is throwing it.

You don't know what the user wants to accomplish when he calls resolve on a non-stored image. It's not an exception as it, you may call resolve just to get the url to be used in some output, and actually store/sync/.. the image later on, e.g. upon KernelEvents::TERMINATE, because you are creating a huge load of filtered images after uploading the source image.

The resolver of this bundle are just fine. They work by interface and contract. If one implements its own logic non-contractual, it's the business of the user to handle unwanted side-effects with the components in use.

[makasim]

thanks for the good explanation. Now I now more about possible use cases of the bundle