|Proposals Table of Contents||Last edited by chrisw on May 15, 2001 5:24 am|
Note - this document is still a work in progress. Please do not make inline comments in the proposal - use the MultiRowManageTabsDiscussion to make comments.
The number of management tabs per object is on the increase and the room is running out in terms of browser width. For example, Squishdot inherits from ZCatalogx, which has it's own set of (very useful) management tabs. To have them all available results in a very wide, but still squashed, management tab bar. Either that, or you haev to leave them out and document the URLsx elsewhere, as I've done with Squishdot right now.
I've noticed that these tabs often come in groups like ZCatalogx in the above example, General object ones (Contents, View, Edit, Upload, History), Security (Permissions, Proxy Roles, Local Roles, User Defined Roles, Allowed Protocols) and so on.
To have items in the Management Tabs row either be pages, like they are now, or groups. If they are groups, a second row of tabs appears below the current ones (maybe in a different colour) which would contain the pages in that group.
This would need to be compatible with the rest of the changes being made for ManagementInterfaceNG
Retrofitting this to stuff that's already there must eb possible but not mandatory.
This project would cover making management groups available but would not cover introducing their use. That would be the responsibility of the product authors. This project would not cover an interface for using groups in ZClass-based products.
changes to the
manage_tabs method to use, show and understand groups.
an extension to the
manage_options mapping enabling but not enforcing the use fo groups.
API docs on how to use Groups.
I worry a bit about changing the underlying datastructures if the main problem is one of (browser) real estate. There are other ways this could be tackled (sub-views of a tab, maybe accessible by a drop-down list for example) using complimentary (and optional) data structures - probably even without any specific support in Zope for that.
Well, the main problem is browser real estate, but I don't think any data structures would need to be changed, just added to. The spelling for defining managment tabs is pretty hairy anyway, maybe a seperate proposal could introduce nice spellings (like we now have for security)
How would you implement your sub-views of a tab as that sounds prettymuch like what I was asking for?
BTW, can someone mail me if they notice anything I should respond to on dev.zope.org, I don't get to stop by here much :-S
© 2000, Digital Creations, Inc. All rights reserved.