Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SUPPORT] Collapse sub menus #123

Closed
fabarea opened this issue Apr 23, 2013 · 5 comments
Closed

[SUPPORT] Collapse sub menus #123

fabarea opened this issue Apr 23, 2013 · 5 comments

Comments

@fabarea
Copy link
Member

fabarea commented Apr 23, 2013

I have a submenu composed by three levels, see in action. I would like to have them collapse by default when I am on this page ("Microdata", ... should go away) but expanded when I am on this one.

Do you see anything wrong in the current implementation? Have I missed something?

I have played with attribute "levels" and "expandAll" but none of them have brought success. I also tried generating the sub-menu without the sub loop as an attempt.

Thanks.

@NamelessCoder
Copy link
Member

Hi Fabien,

The current implementation in the template would be the same as expandAll="TRUE" levels="{number}" but with manual rendering. It seems what you need is a way to check if the page being rendered is contained in the root line (done in each level):

<v:page.menu ...>
    <v:iterator.contains haystack="rootLine" needle="{page.uid}">
        <f:if condition="{menu}">
            ...
        </f:if>
    </v:iterator.contains>
</v:page.menu>

(v:iterator.contains is a condition VH)

This should expand the menu items only when the current page is part of the menu array being rendered. Hope this helps :)

Cheers,
Claus

@fabarea
Copy link
Member Author

fabarea commented Apr 24, 2013

Just to get it right. Is the "manual" rendering mandatory for this case? I tried also what follows but didn't get then the menu expanded (actually submenu of level 2, .. are never rendered). It would be much less code if I could make this work... Would the View Helper be able to recursively iterates with the inner code for its submenu? In this case <nav role="navigation"> would need to be outside.

    <v:page.menu entryLevel="1" useShortcutData="true" expandAll="true" levels="3">
        <f:if condition="{menu}">
            <nav role="navigation">
                <ul class="nav nav-list bs-docs-sidenav affix-top">
                    <f:for each="{menu}" as="menuPage" iteration="iteration">
                        <li class="{menuPage.class}">
                            <a tabindex="{iteration.cycle -> v:math.sum(b: 100)}"
                               href="{menuPage.link}" class="{menuPage.class}">
                                <i class="icon-chevron-right"></i>{menuPage.title}
                            </a>
                        </li>
                    </f:for>
                </ul>
            </nav>
        </f:if>
    </v:page.menu>

@NamelessCoder
Copy link
Member

Is the "manual" rendering mandatory for this case?

Yes, since you require tabindices, a <nav> container and an added icon inside the link.

Would the View Helper be able to recursively iterates with the inner code for its submenu?

Not at this time, but I suppose it wouldn't be too much to create an alternative "autoRender" method which instead of creating tags, renders the child content for every menu level, but apart from that works exactly like "autoRender" regarding expandAll etc.

You of course already know this, but if you move the <nav> tag out of the tag contents you can't avoid rendering it if there is no menu. Depending on CSS that might become a problem.

If you see a use for this addition to the menu ViewHelper (and it would encompass all menu VHs) we can make a feature request for it - if at all possible, it would then be part of the next release :)

@fabarea
Copy link
Member Author

fabarea commented Apr 24, 2013

Alright, it has worked with <v:iterator.contains haystack="{rootLine}" needle="{menuPage.uid}">. However, it seems a patch is needed because the rootLine has uid as key of the array and the v:iterator.contains only checks values of the array (i.e. array_search). The patch is pretty straight forward solving my case. However, you could see some edge cases the way the problem solved.

@NamelessCoder
Copy link
Member

Hi Fabien,

Hope my suggestions in #124 allows you to solve the problem! If so, let's close this one (but optionally leave the PR open for more work, if you think of another use case I overlooked).

Cheers,
Claus

@fabarea fabarea closed this as completed in 9900ef6 May 2, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants