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
Enable 'back' GET parameter management #13233
Enable 'back' GET parameter management #13233
Conversation
@matks its more likely like POC here. Can you have a quick look to it and let men know if I shall finalize it with tests? |
src/PrestaShopBundle/Twig/Extension/PathWithBackUrlExtension.php
Outdated
Show resolved
Hide resolved
src/PrestaShopBundle/EventListener/BackUrlRedirectResponseListener.php
Outdated
Show resolved
Hide resolved
🎉 very nice way to use Symfony built-in features to handle this usecase 😄 |
src/PrestaShopBundle/Twig/Extension/PathWithBackUrlExtension.php
Outdated
Show resolved
Hide resolved
done - waiting for response in #13233 (comment). After the response, I'll re-apply tests |
/** | ||
* @param RequestStack|null $requestStack | ||
*/ | ||
public function __construct($requestStack) |
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.
Let's avoid injecting the RequestStack in services if we can 😉and here we can ! (see https://igor.io/2013/03/31/stateless-services.html for detailed explanation about this matter)
You can pass the request in public function getBackUrl(Request $request)
.
2 side-effects that are great benefits (apart from the benefit number one which is "do not depend on request stack"):
- we can use this service in CLI !
- we can use this service on multiple Requests to retrieve the back parameter, not only the one provided by RequestStack
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.
great article! Indeed it was easy to avoid RequestStack in that service - got reduced its usage and right now it is used in PathWithBackUrlExtension
twig extension only.
… if current request has back url - it modifies current request and returns copied original request with different url
…t and response objects - e.g "save and stay" functionality
…is being injected
…o confirm the functionality of the redirect response listener
03e5e6a
to
c31f1d7
Compare
@matks - let me know if this PR can be approved. Once I know its good to go I'll add docs about it :) |
arguments: | ||
- '@twig.extension.routing' | ||
- '@prestashop.core.uti.back_url_provider' | ||
- '@=service("request_stack") ? service("request_stack") : null' |
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 did not know you could do 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.
Yes, that's really handy if you have "optional" dependencies, like from different libraries/bundles
@tomas862 just one question: why did you change the name of the GET parameter from "back" to "back-url" ? |
@matks well "back-url" made more sence for me since for word "back" has a greater chance that it might be used in a different context. and since it is applied only for migrated pages "backward compatability" issue does not exist - the only issue that I see is that when someone will be migrating the pages they should not forget to add "back-url" instead of using "back". Howerer, using "back" or "back-url" does not make much impact so I can change to "back" again easily if you see its more proper :) |
I was thinking of people using |
@matks you're right - there would be a chance if someone is using |
Thanks @tomas862 |
Write unit tests
Write documentation.
This change is