Hey there.
I’m going to explain what I need and what I’m going to do.
Maybe someone has a better idea and can share it.
Maybe what I’m doing is just the way it’s supposed to be. Then I’m just rubberdrucking here.
What I need to do:
One plugin one document node needs to create a link to a different plugin on a different document node.
I’m creating custom plugins that have – at least for the sake of this example – one controller and two actions both in individual neos content node types.
The listAction shows a list of objects.
The showAction shows details of a single one.
Both actions are distinct plugins on distinct pages because my customer wants to add individual content on both pages and be able to adjust those, just like on regular pages.
Hint for why I don’t use document node types:
Source for my objects is a remote service that changes its content every couple of minutes. So importing them as nodes isn’t a good idea because this would result in publishing workspaces literally every two minutes.
Creating AJAX stuff is due to legal issues not an option as well.
What I already know:
The f:link.action ViewHelper has an UriBuilder which has the current ActionRequest pointing to my plugin.
The request to my plugin is a sub request to the Frontend/NodeController::show($node).
The f:link.action ViewHelper doesn’t know anything about the NodeController. By default, it creates an URI pointing to a “sibling of my ActionRequest” and takes all parentRequest settings just “as is”. In fact, the ViewHelper doesn’t even now about my current request being an ActionRequest already.
Three ways to have this solved:
- Either it’s the ViewHelpers task to somehow adjust the parentRequest. Of course rewriting requests isn’t a good idea and I would need to recreate a completely new one with slightly different arguments. But for the sake of this explanation, let’s call it rewriting the parent request. That could work, and since the ViewHelper is very well aware of sub requests situations, adding that tiny little thing somehow fits the scope of the ViewHelper. Of course that would tightly couple the ViewHelper to neos, which is both, breaking and not a good idea at all.
- Or it’s the UriBuilders duty to find out: There’s a an URI created, targeting plugin configuration that doesn’t fit the node it is pointing to. I can think of some AOP magic just wrapping the
UriBuilder::build()method, so it wouldn’t even be and adjustment of the UriBuilder itself. - Since both former methods involve magic, there could be a distinct ViewHelper
whtever:uri.actionOnForeingNode()that takes both, the action arguments as well as the target node the other plugin is on.
Way too complicated
I’m getting the impression: There needs to be another way I didn’t think of yet, and I’m just holding it wrong.
Any ideas?
Regards,
Stephan.