Skip to content
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

[1.0][resolver] remove request parameter #281

Merged

Conversation

makasim
Copy link
Collaborator

@makasim makasim commented Dec 9, 2013

@havvg squashed and rebased over develop branch version. Hope I dont lost anything while rebase.

This is the work I did (that come with next PRs after this one is merged):

There other changes I am currently working on (would not be included in this PR):

  • ResolverInterface::resolve method return null or Response
  • ResolverInterface::store accept $path. right now it require $targetPath
  • ResolverInterface::store would return anything.
  • FilterManager::applyFilter takes third parameter runtimeConfig. It would allows configure filters in runtime.
  • FilterManager::get was removed.
  • ...
    ...

these changes could be found in the branch https://github.com/formapro-forks/LiipImagineBundle/tree/resolver-do-not-expose-target-path

{
$this->setBasePath($request->getBaseUrl());
$this->setBasePath($this->container->get('request')->getBaseUrl());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/liip/LiipImagineBundle/pull/278/files#r8191764

@makasim There is no interface yet, you should introduce it with this patch: Liip\ImagineBundle\Imagine\Cache\Resolver\RequestAwareInterface with a setRequest method only, just like https://github.com/symfony/symfony/blob/master/src/Symfony/Component/DependencyInjection/ContainerAwareInterface.php.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@havvg how should this method be used?

I cannot inject request as a service because in this case I have to put resolver to request scope and all services that use the resolver too. I dont think this would work.

Or are you about injectig request with strict="false" to prevent scoping errors

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we can update minimum supported version of symfony up to 2.3 we can use synchronized services feature.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with changing the required version to 2.3 as it's an LTS, we should encourage upgrading to this version. The 0.x version line will still be available for older versions.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so I am gonna update required symfony version up to 2.3 and use synced services.

@makasim
Copy link
Collaborator Author

makasim commented Dec 9, 2013

@havvg done, I've also added some functional tests, more would come with other PRs.

@havvg
Copy link
Contributor

havvg commented Dec 9, 2013

Could you squash the commit and add empty newlines where missing?

@makasim
Copy link
Collaborator Author

makasim commented Dec 9, 2013

Could you squash the commit and add empty newlines where missing?

@havvg done

{
$this->setBasePath($request->getBaseUrl());
if (false == $this->request) {
throw new \LogicException('The request was not injected, inject it before using resolver.');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about changing the injection to the constructor? There is no use to those resolvers (NoCacheResolver & WebPathResolver) without the request. This would also remove duplicate code of this check.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think it is possible, container should have ability to change request service on sub request and set it to null when we out of request scope.

That's simply not possible with constructor injection.

I would suggest

  • to move the logic to AbstractFilesystemResolver.
  • or we could also try to use router context to get base url. I believe it is not in the request scope so we can inject it using constructor

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

honestly saying I would drop NoCacheResolver (or rename it) because it could work only with WebPathResolver.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any chance to merge it without change request related stuff? WebPathResolver requires separate PR with cleanups and refactoring. So maybe we can address this request realted duplications to that time?

@makasim
Copy link
Collaborator Author

makasim commented Dec 10, 2013

@havvg moved request injection to base class.

@makasim
Copy link
Collaborator Author

makasim commented Dec 10, 2013

@havvg bay the way there is kind of mess with that AbstractFilesystemResolver::basePath property. It is set by setter and used everywhere except resolve method where the value from request is used. This must be fixed somehow.

@@ -176,8 +176,7 @@

<!-- Cache resolver -->

<service id="liip_imagine.cache.resolver.web_path" class="%liip_imagine.cache.resolver.web_path.class%">
<tag name="liip_imagine.cache.resolver" resolver="web_path" />
<service id="liip_imagine.cache.resolver.abstract_filesystem" class="Liip\ImagineBundle\Imagine\Cache\Resolver\AbstractFilesystemResolver" abstract="true" public="false">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use a class name parameter for this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is not really useful

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you see any real use case where one would want to overwrite it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you can rename the classes of the resolvers, you should also be able to rename its parent class, as it might have changed, too, altering the complete class tree.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I would remove the name completely in favor of the abstract attribute on the service.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The abstract=true ensures you cannot create the service, thus the class attribute can be removed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@havvg done: remove class name. Also squashed and rebased.

@makasim
Copy link
Collaborator Author

makasim commented Dec 10, 2013

bump @havvg

havvg added a commit that referenced this pull request Dec 10, 2013
…arameter

[1.0][resolver] remove request parameter
@havvg havvg merged commit 6796e2f into liip:develop Dec 10, 2013
@havvg
Copy link
Contributor

havvg commented Dec 10, 2013

Thank you!

@havvg
Copy link
Contributor

havvg commented Dec 10, 2013

I will take an insight look into your fork this evening, you mentioned some changes I would like to see in the 1.0.0 release version.

@makasim
Copy link
Collaborator Author

makasim commented Dec 10, 2013

@havvg I would split it into pieces and do small PRs in the main direction of that branch. They would come soon

@makasim makasim deleted the resolver-remove-request-parameter branch December 10, 2013 12:55
@havvg
Copy link
Contributor

havvg commented Dec 10, 2013

That would be great, small pieces to select and discuss accordingly, looking forward to it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants