Forgot your password?
New user?
Document Actions
#116: Improved Large Folder behaviour and user interface
- Contents
- Proposed by
- Alexander Limi
- Proposal type
- User interface
- State
- being-discussed
Definitions
- Large Folder
- Here used as a common term for any BTree-based folder, which are designed to hold thousands of elements. They are not the same in all cases, but the improvements proposed here are applicable to any BTree-based folder structure.
Motivation
Currently, Plone has a content type for holding thousands of items that is based on a BTree structure called the Large Folder, that supports thousands of content items in an efficient way - and has no ordering support.
This content type is created for a radically different use case than the normal folder, and should have an interface and a behaviour that matches and optimizes this usage.
There are three main areas where Large Folders could use improvement:
- Behaviour in the navigation tree
- The interface when manipulating the contents of the folder (potentially containing thousands of items)
- The view of the folder
Proposal
The changes proposed are:
- Navigation tree changes
- Large Folders should not expand in the navigation tree. The currently selected item should be there, but its sieblings should not be shown. This is an obvious change, since there could easily be thousands of items in the navigation tree.
- Folder Contents view changes
- The Folder Contents view of a Large folder should be search-based. Ideally, we want this to be a LiveSearch-like implementation of the table view that is the contents view of a normal folder.
- Default view changes
- The default view of a Large Folder should at the very least have batching — and preferrably have a search-based interface like the Folder Contents one, if possible.
Risks
We should evaluate what developers are available for this PLIP and go for the non-LiveSearch-like implementation if we don't have the available resources to do it properly.
Progress log
This is the second part of the folder contents updates; no bundle for the deadline here either since it needs a decision in the AJAX discussion. (There are of course parts that could have been done in the meantime, but it's always harder to motivate people when there's no UI on top ;)
Sounds good to me
Faster objectIds() would be good, I don't think we'll be using it outside of calculating the number of items, though.
Keywords
tag-based btree browsing
I think this idea is Great(tm).
another improvement, underneath suggested
Catalog-backed folder_contents is good; making large folders have a search-not-browse UI is as well. However, there are also cases for using objectIds() (still used by some applications on top of Plone for certain operations not driven by the catalog - also useful for len(self.objectIds()) as well) - BTreeFolder2.objectIds() out-of-the-box doesn't scale, but there is an easy fix that makes objectIds() much faster for tens-of-thousands of items and possible for hundreds of thousands of items (we are using in CMFMember setup wtih 200k+ users). I've proposed a patch (http://mail.zope.org/pipermail/zope-dev/2006-January/026585.html) for BTreeFolder2, but haven't lobbied hard to get a Zope committer to push this into BTreeFolder2 - it could also go into a subclass like BaseBTreeFolder or anywhere else in AT/Plone? Anyone interested?