|
| Summary: |
Filter Give XClasses categories, and let the XClass picker by category, using a category: prefix in its search field filter on them |
| Description: |
h2. 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 sheet bindings , and the like). This is already noise in It has exactly two callers today, both advanced editors: the object editor ({{editobject.vm}}) and the class editors, and it editor ({{editclass.vm}}). This becomes a real an 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 Proposal, option 5.2 of the proposal : https://forum.xwiki.org/t/improve-the-listing-of-xclass-in-the-xclass-picker/18766/7
h2. Categories on XClasses
Give XClasses A category is a set of categories raw , following capitalised string id ({{Internal}}, {{Deprecated}}, {{Development}}), and an XClass carries zero or more of them. This follows the conventions already used for macro categories : , including the two special ids {{Internal}} and {{Deprecated}}.
* an XClass can carry several categories (e Display labels resolve through the {{xclass . g category . <Id>}} translation keys, falling back to the raw id when no translation exists, so a category created on a wiki is usable with no configuration.
Categories are stored as a {{ Development categories }} meta-property of {{BaseClass}}, next to the existing {{validationScript}} and {{ Internal customMapping }} ) . In the XAR they are a single {{<categories>}} element holding a comma-separated list , which matches the flat-string shape of every other class meta-property. A comma is therefore not allowed in a single flag category id.
* two
They are set in the class editor, alongside the other class meta-properties.
h2. Filtering in the picker
Which categories are special hidden is decided by the *caller* of the picker , not by the advanced-user flag: the object and class editors are themselves advanced tools and must keep seeing everything. The {{ internal classPicker }} and macro takes a {{ deprecated hiddenCategories }} exclusion parameter that defaults to empty , and so both existing callers are hidden from unaffected, and a caller aimed at non- advanced technical users passes {{Internal}} and {{Deprecated}}.
* an
An XClass carrying neither with no category is considered non-technical, so existing XClasses stay visible by default
h2 always shown . Filtering in There is no way to exclude the picker uncategorised ones, because a wiki's own hand-made classes have no category either and hiding them would defeat the purpose.
The filtering Filtering happens in the picker's existing search field , through a {{category:}} prefix, rather than through a second filtering field -- the . The picker is a compact dropdown and should stay one embedded in someone else's form, unlike the macro selector which is a full modal dialog with room for a multi-select :
* {{category:photography}} returns every XClass in the {{photography}} category
* {{meetings category:projectmanagement}} returns every XClass whose name contains title matches {{meetings}} and that belongs to is in the {{projectmanagement}} category
Matching is case-insensitive and by prefix, against both the category id and its translated label. Several {{category:}} terms are combined with AND, as the macro picker does.
h2. Left to decide Displaying categories
* how a category The matching categories are displayed as badges on the dropdown rows, inside the existing per-space option groups, using the translated label. The space grouping is stored unchanged, and the selected item shows no badge.
h2. Configuration
A single instance-wide property, {{xclass.categories}} in {{xwiki.properties}}, reassigns the categories of a given XClass, mirroring {{rendering.transformation.macro.categories}} :
{code}
xclass.categories = Blog.BlogPostClass = Blog,Content
{code}
This is what lets an XObject added to the administrator categorise an XClass page shipped by an extension they do not control. There is deliberately *no* global hidden-categories property: hiding is the caller's decision , or and a global setting would silently remove classes from the object editor.
h2. Implementation notes
* the picker renders the full class list server-side from {{ BaseClass $xwiki.classList }} and filters it client-side through xwiki-selectize (Tom Select), so no query is involved and the meta-property (options 2 needs no index
* the picker template already loads every class document to render its title, so reading the meta-property costs no additional document load
* the {{category:}} support is a {{classPicker}}-scoped override of the Tom Select search, not a change to the shared {{xwiki . 1 selectize.js}}, which backs the user, page and 2 attachment pickers as well
h2 . 2 Scope
Categorised as part of this issue, to exercise the proposal) mechanism: {{XWiki.XWikiRights}} and {{XWiki.ClassSheetBinding}} as {{Internal}}, and {{Blog.BlogPostClass}} as {{Content}}.
* which categories to set on
Reviewing and categorising all the XClasses currently shipped by XWiki , and the migration this implies is a follow-up issue.
|
|
