Ability to replace/decorate LinkGenerator.

[tg666]

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]

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.

[Antarian]

I am not sure if there is any point in having final and private methods and variables in the abstract public-facing class like Application/UI/Presenter.
Internal methods may be marked as @internal to count for BC, and otherwise, I would say things there should be possible to override/customize.
Good example here is Symfony's AbstractController where only private methods is related to Twig and used by protected methods which can be overridden.
https://github.com/symfony/framework-bundle/blob/7.2/Controller/AbstractController.php#L250