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

Ability to replace/decorate LinkGenerator. #333

Open
tg666 opened this issue Oct 11, 2024 · 1 comment
Open

Ability to replace/decorate LinkGenerator. #333

tg666 opened this issue Oct 11, 2024 · 1 comment

Comments

@tg666
Copy link

tg666 commented Oct 11, 2024

Hi,
In the version v3.2.3 was a change in the links generation, respectively the request creation - the logic was moved from the presenter to the LinkGenerator class.
This is a great change in itself, as the link generation is now identical in both Presenter and LinkGenerator.
However, you cannot now overload the createRequest() method, which is something we used to use in our projects.

In our applications, we use a lot of modals (or other similar components that overlay the main content of the site) and the modals can overlap each other (one modal can open another).

These modals are not opened by AJAX only, but are also referable. So it is possible to send another person a link to a specific modal. The modal parameters are of course persistent, without that it wouldn't work.

The problem arises when the user comes to the page from a link where some modals are open (or opens the modals themselves via AJAX and refreshes the page). At this point, the links in the Presenter/components below the modal are generated incorrectly, because they contain persistent parameters of all opened modals.

For this reason, we overloaded the Presenter::createRequest() method, where depending on the context (argument $component) we set needed persistent parameters to null.

My question is whether it would be possible to make LinkGenerator available to overload in any way.
I think this is a valid modification, as there is currently no satisfactory way to change the framework's behavior in this regard.

Currently we have solved this by having our own LinkGenerator and overloading the Presenter methods link(), isLinkCurrent(), redirect() and redirectPermanent(), which is not exactly a dazzling solution.

The solution may be simple.

  • Add the ILinkGenerator interface that the LinkGenerator class will implement.
  • The Presenter::getLinkGenerator() method will not be final.

or

  • Since I know that Nette disappears I prefixes from interfaces and the Interface postfix is not acceptable, the LinkGenerator interface could be created.
  • The LinkGenerator class will be renamed in any way (for example, DefaultLinkGenerator or the name will remain, but moved to a different namespace) and will implement the LinkGenerator interface. This change will not break autowiring of the LinkGenerator service.
  • The Presenter::getLinkGenerator() method will not be final.

Or any other solution that would allow the LinkGenerator to be extended/decorated.

Thanks for your time!

@MartinMystikJonas
Copy link

This would be also very useful for tests. Now we need to do heavy magic to replace final class with mocks in container during test instead of using testing implementation of LinkGenerator.

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

No branches or pull requests

2 participants