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 >> > --
