Menu Bundle

Menu Items

You can create items either as a single stand-alone item, or directly as a child of another item:

use Becklyn\Menu\Item\MenuItem;

$parent = new MenuItem("parent");
$child = $parent->createChild("child");

// --------------- or ---------------

$parent = new MenuItem("parent");
$child = new MenuItem("child");

$parent->addChild($child);

$item->setExtra("pageId", 75);

<div data-page="{{ item.extra("pageId") }}">...</div>

$parent = new MenuItem();
$child1 = $parent->addChild("child1", ["key" => "ohai"]);
$child2 = $parent->addChild("child2");

assert($child1 === $parent->find("ohai"));

{{- menu_render(item.find("some-key")) -}}

Rendering Menus

You first need to fetch the menu item, which should be rendered. It will only render the children of this item, not the item itself.

You can render in PHP:

use Becklyn\Menu\Renderer\MenuRenderer;

public function doSth (MenuRenderer $renderer)
{
    $root = $this->getRoot();
    $options = [];

    return $renderer->render($root, $options);
}

and you can render in Twig:

{{- menu_render(item, options) -}}

Item Visitors

You can register custom visitors that will be called for every menu item and can modify them. The whole interface of the menu item can be used, so you can:

• add children
• set extras
• overwrite the label (for example manually translate the label with custom translation parameters)
• …

You need to implement the ItemVisitor interface:

use Becklyn\Menu\Visitor\ItemVisitor;

class MyVisitor implements ItemVisitor
{
    /**
     * @inheritDoc
     */
    public function visit (MenuItem $item, array $options) : void
    {
        $item->setExtra("randomNumber", random_int());
    }

    /**
     * @inheritDoc
     */
    public function supports (array $options) : bool
    {
        return true;
    }
}

You can either let your service be autoconfigured (by just using the Interface and adding it to the container) or add the tag manually: becklyn.menu.visitor.

App\Menu\MyVisitor:
    tags:
        - name: becklyn.menu.visitor
          priority: 100

There are two core listeners, here with their priorities:

• CoreVisitor (-1000): applies the security and resolves LazyRoute s.
• VoterVisitor (-1500): applies the voter to the item.

Keep the order of the visitors in mind: your own visitor should run before the voter visitor, if your changes might influence the result of the selected item voting.

Each visitor will be passed the render options. Your visitor must decide whether it supports the current rendering according to the render options. If true is returned, the visitor will be called for all menu items, if false is returned, the visitor will never be called. The supports() method will be called before each render process.

Item Voters

Voters are also called for every item and decide whether this item is active.

You need to implement the interface:

use Becklyn\Menu\Voter\VoterInterface;

class MyVoter implements VoterInterface
{
    /**
     * @inheritDoc
     */
    public function vote (MenuItem $item) : ?bool
    {
        // sorry not sorry
        $item->setCurrent(random_int(0, 10) > 5);
    }
}

Your voter can either decide the decision by returning true (= is active) or false (= is not active), or it can abstain from the vote by returning null.

There is one core voter, with priority 0, that is automatically registered. It just checks that the route of the current request matches the route in the item (it ignores items with no target / URL target, as well as route parameters).

For that visitor to work, the core visitor will store the route of all LazyRoute s (before transforming them to URLs) in an extra attribute called _route. This attribute will then be checked by the core voter to match the current request route.

If you create custom items with a URL, you can set this extra key manually, to opt-in to matching this item to some requests.