Set current uri #55

merged 4 commits into from Jul 30, 2011


None yet

5 participants


This PR extends #53 to automatically set the current uri from the request in MenuHelper.

benjamindulau and others added some commits Jul 27, 2011
@benjamindulau benjamindulau When rendering the menu through a twig template, the depth option.
Also, the depth default value is now 1 instead of null, which is IMO the most common use case.
@benjamindulau benjamindulau * Removed unused "path" option in MenuExtension and MenuHelper
* Default of the depth option is back to "null"
@uwej711 uwej711 Merge remote-tracking branch 'benjamindulau/FixingDepth' into set_cur…
@uwej711 uwej711 Automatically set the current request uri to the menu
To make adding the class current to the current menu item work, there
needs to be a way to inform the menu of the current request uri. This
can be done, when the menu is fetched from the menu provider in the
@mbontemps mbontemps merged commit 9ef5600 into KnpLabs:master Jul 30, 2011
@stof stof commented on the diff Jul 30, 2011
@@ -37,7 +37,9 @@ class MenuHelper extends Helper implements \ArrayAccess
public function get($name)
- return $this->provider->getMenu($name);
+ $menu = $this->provider->getMenu($name);
+ $menu->setCurrentUri($this->container->get('request')->getRequestUri());
stof Jul 30, 2011

this causes an issue when rendering the menu in a subrequest as the request uri will be the wrong one and you force using it.

uwej711 Jul 31, 2011

Would it make sense to make this configurable? I think there are cases where no subrequests are used ... or is there a better way to find out the original uri?

stof Jul 31, 2011

From a subrequest, you cannot know the main request uri, even more when the subrequest is delayed by using ESI.

uwej711 Aug 1, 2011

So what do you think about making that configurable? From what you said I guess marking the current menu item automatically will never work when using sub request.

dbu Aug 3, 2011

did you find a solution to the issue? or how could an ESI sub request for the menu with correct highlighting work? pass a magical parameter to highlight the right entry? maybe we could add support for passing the highlighted path as a get parameter with configurable name?...

stof Aug 3, 2011

I don't think we should add some magic to choose a get parameter (what if the user passes it as request attribute which is easier when creating subrequests ?)
We should simply make the automatic retrieval of the current uri configurable.

dbu Aug 3, 2011

yes, makes more sense than randomly adding something and the users of the lib needing to roll their own thing. shall we create an issue on the issue tracker for this topic?

stof Aug 3, 2011

yeah probably. It would be easier to track it that way than commenting on another PR.

dbu Aug 3, 2011

i think this also has a relation to the issue 48 #48 by @cirpo . should we create a new issue or discuss in 48?

@uwej711: or was there a different reason for needing the request url known in the menu?

stof Aug 3, 2011

I think this PR is just about lazyness to avoid having to set the current uri when building the menu :)

dbu Aug 3, 2011

created #56 to track this further. its a general issue in fact. but i think uwe should still check out #48 because we wanted to solve that problem originally...

@bamarni bamarni referenced this pull request Nov 9, 2012

Adds a controller voter #133

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment