You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can see this got carried over from Boxmenu however I don't think this is needed. We typically use menu groups for two reasons:
Bespoke layouts - if you want to wrap menu items in containers to give more flexibility in the styling of menus (grid layouts).
Section up content.
For both instances, we can do this by using multiple menuBox components. Blocks give us the flexibility with the layout as well as breaking up the menu structure (grouping content).
I've yet to test the group functionality with the Introduce Menus as Pages PR as I wanted to query this before doing so. From a setup perspective, I think I would find it easier to think of menuBox as a component and use blocks for structure rather than enabling the group config I associate with Boxmenu.
Using blocks to group items rather than the group config would give us more flexibility with menu design too e.g. displaying other components between menu items.
I'm not sure what the impacts are with menu locking/completion etc so this will need consideration.
The text was updated successfully, but these errors were encountered:
I don't think there would be multiple instances of this particular plugin. This is effectively just the boxMenu behaviour, but as a component, including the grouping behaviour as standard.
Multiple instances are much harder to configure as one would need to refer to sub-pages or sub-menus (groups) by id, or some other filter category. The standard menuBox should be easy to configure in the AAT, by just dropping it onto a page.
More generally speaking, locking is inherited from the course structure and the AdaptModel locking functions along with the other locking attributes, to set _isLocked for each page/menu item, it's much less to do with how the content objects are rendered. i.e. If a content object has _isLocked = true render it as locked.
But yes. Absolutely. I agree with all the aforementioned requirements. If we get the core pr in first, we can then consider how to do a menu with multiple menu components and how to choose the child contentobject for each instance.
I can see this got carried over from Boxmenu however I don't think this is needed. We typically use menu groups for two reasons:
For both instances, we can do this by using multiple
menuBox
components. Blocks give us the flexibility with the layout as well as breaking up the menu structure (grouping content).I've yet to test the group functionality with the Introduce Menus as Pages PR as I wanted to query this before doing so. From a setup perspective, I think I would find it easier to think of
menuBox
as a component and use blocks for structure rather than enabling the group config I associate with Boxmenu.Using blocks to group items rather than the group config would give us more flexibility with menu design too e.g. displaying other components between menu items.
I'm not sure what the impacts are with menu locking/completion etc so this will need consideration.
The text was updated successfully, but these errors were encountered: