Having it both ways will be a mess. We need to choose one way. On Wednesday, 22 August 2012 06:57:32 UTC-5, villas wrote: > > Regarding the menu, I can see there is a point in having both: > > 1. The 'menu field' may be better for anyone wishing to change the menus > dynamically. > 2. The 'menu page' is ideal for those wishing to visualize the menu in one > easy place. > > My other reason for suggesting that is because you have already written > the code for both. > > Maybe it could be implemented with the automenu parameter: > automenu='field' | 'page:nameofmenupage' | None > > If you think it is overkill to have two menu schemes, then I would choose > the plugin_wiki 'menu page'. That was so simple that I managed to teach > someone else to use it in seconds, and that doesn't happen very often! > > Thanks, D > > > On Wednesday, August 22, 2012 4:22:10 AM UTC+1, Massimo Di Pierro wrote: >> >> 2. ok in trunk. >> 4. fixed in trunk >> 2+3. >> >> right now the menu field is a path: >> >> /menu/submenu/subsubmenu >> >> and based on the path the page is added to the menu. You can sort manues >> with >> >> /0:menu/2:submenu/3:subsubmenu >> >> so menu is the top first top menu item, submenu is the second item in the >> menu submenu, etc. >> For one more day is still negotiable. Do you prefer and approach like >> plugin_wiki instead? (all menu items in one page)? >> >> >> >> >> >> >> On Tuesday, 21 August 2012 19:33:37 UTC-5, villas wrote: >>> >>> 1. How does the menu field work? >>> >>> 2. Are we going to expose automenu option for auth.wiki(automenu=False)? >>> A separate top level menu for each page is impractical, so at least we >>> could turn it off. >>> >>> 3. Can we have a configurable menu like we had with meta-menu on >>> plugin_wiki? I think that is great. >>> >>> 4. BTW the link to Database Admin button doesn't seem to work at the >>> moment (appadmin). >>> >>> Many thanks, David >>> >>
--
