MultiRowManageTabs of Proposals

Proposals Table of Contents

Last edited by chrisw on May 15, 2001 5:24 am

FrontPage
- MultiRowManageTabs / backlinks

MultiRowManageTabs Proposal

Note - this document is still a work in progress. Please do not make inline comments in the proposal - use the MultiRowManageTabsDiscussion to make comments.

Contact

ChrisW

Problem

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 ZCatalog^x, 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 URLs^x elsewhere, as I've done with Squishdot right now.

I've noticed that these tabs often come in groups like ZCatalog^x 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.

Proposed Solution

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.

Risks

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.

Scope

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.

Deliverables

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.

Brian (May 4, 2001 2:41 pm; Comment #1)

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.

chrisw (May 15, 2001 5:24 am; Comment #2)

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