Context The XClass picker (the classPicker Velocity macro of macros.vm) lists every XClass the current user can view, with nothing to distinguish a business XClass (a Meeting or a Recipe, created through AWM or by hand) from a purely technical one (rights, comments, and the like). This is already noise in the object and class editors, and it becomes a real obstacle as soon as the picker is offered to non-technical users -- for instance in a macro that lets them pick an XClass, choose the properties to display, and get a Live Data out of it (XWIKI-24831). This is option 5.2 of the proposal http://forum.xwiki.org/t/improve-the-listing-of-xclass-in-the-xclass-picker/18766/7 Categories on XClasses Give XClasses a set of categories, following the conventions already used for macro categories:
- an XClass can carry several categories (e.g. Development and Internal), not a single flag
- two categories are special, internal and deprecated, and are hidden from non-advanced users
- an XClass carrying neither is considered non-technical, so existing XClasses stay visible by default
Filtering in the picker The filtering happens in the picker's existing search field, through a category: prefix, rather than through a second filtering field -- the picker is a compact dropdown and should stay one:
- category:photography returns every XClass in the photography category
- meetings category:projectmanagement returns every XClass whose name contains meetings and that belongs to the projectmanagement category
Left to decide
- how a category is stored: an XObject added to the XClass page, or a BaseClass meta-property (options 2.1 and 2.2 of the proposal)
- which categories to set on the XClasses currently shipped by XWiki, and the migration this implies
|
