🏆 A full-stack component-based MVC kernel for PHP that helps you write powerful and modern web applications. Write less, have cleaner code and your work will bring you joy.
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.
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.
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 theLinkGenerator
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 thecreateRequest()
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 tonull
.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()
andredirectPermanent()
, which is not exactly a dazzling solution.The solution may be simple.
ILinkGenerator
interface that theLinkGenerator
class will implement.Presenter::getLinkGenerator()
method will not befinal
.or
I
prefixes from interfaces and theInterface
postfix is not acceptable, theLinkGenerator
interface could be created.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 theLinkGenerator
interface. This change will not break autowiring of theLinkGenerator
service.Presenter::getLinkGenerator()
method will not befinal
.Or any other solution that would allow the
LinkGenerator
to be extended/decorated.Thanks for your time!