Wiki source code of AWM Core Change Sheet Display
Last modified by Vincent Massol on 2026/08/05 16:03
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | In order to support the Application Within Minutes Project we need an XWiki core change to automate the display of a sheet on specific pages without having the use the "include" mecanism. | ||
| 2 | |||
| 3 | The benefits of this is to make wiki page with and without objects be the same. This will remove the "inline" editing mecanism. | ||
| 4 | |||
| 5 | The proposed approach is to have a notion of "views". These views can be applied in VIEW or EDIT, but also possible SEARCH, or CHANGES display. | ||
| 6 | |||
| 7 | A view can be then applied whenever data of a specific type of page (containing a specific object for instance) is displayed. | ||
| 8 | |||
| 9 | == View Resolution == | ||
| 10 | |||
| 11 | View resolution can be a bit complex as we could have cases of conflicts. In order to have an efficient view resolution we need to implement it in an XWiki API. This API acts as a resolver and can implement a cache for more efficiency. | ||
| 12 | |||
| 13 | It could be the resolveView API which returns an object structure | ||
| 14 | |||
| 15 | {{code}} | ||
| 16 | #set($docview = $doc.resolveView()) | ||
| 17 | {{/code}} | ||
| 18 | |||
| 19 | The VIEW structure would have the following apis: | ||
| 20 | |||
| 21 | * getCreateSheet() (for create) | ||
| 22 | * getViewSheet() (for view) | ||
| 23 | * getEditSheet() (for edit) | ||
| 24 | * getSearchSheet() (for custom search display) This could only apply to displaying ONE search result of the matching type | ||
| 25 | * getChangesSheet() (for custom changes display) This could only apply for the changes display of a specific OBJECT or the full changes page, or there could be 2 sheets one for the full changes page and one for an individual change. | ||
| 26 | * getListSheet() (for custom list/livetable display) | ||
| 27 | |||
| 28 | The return is an page name. The page contains the script with the view code, but also can contain additional parameters including: | ||
| 29 | |||
| 30 | * display of each tab in the view mode | ||
| 31 | * display of editable title in edit/create mode | ||
| 32 | * display of version summary in edit mode | ||
| 33 | * display of editable breadcrumb in edit mode | ||
| 34 | * configuration of the action buttons in edit mode | ||
| 35 | * configuration of panels in edit mode | ||
| 36 | |||
| 37 | The options should allow to have about the same possibilities as the one we had with the two edit modes ("wiki edit"/"inline edit"). | ||
| 38 | |||
| 39 | == View Resolution Rules == | ||
| 40 | |||
| 41 | The resolution rules proposed are: | ||
| 42 | |||
| 43 | * Look in the document if any custom view is declared. If yes use it. | ||
| 44 | * Look in the document objects if their object type declare a view. If yes use the first one. | ||
| 45 | * If multiple ones, use an optional rule precedence declared in the preferences | ||
| 46 | * If none found use the standard view | ||
| 47 | |||
| 48 | == View Resolution Rules Storage == | ||
| 49 | |||
| 50 | The XWiki Document and XWiki Class already contain some fields for VIEW/EDIT/SEARCH sheet declaration. Additional fields might be needed. | ||
| 51 | |||
| 52 | == Changes needed in the templates == | ||
| 53 | |||
| 54 | The templates handling view/edit/changes/search will have to call the resolver to decide which sheet to use. If none is found the standard view template will be used. | ||
| 55 | The rendering of the EDIT button will not need any specific handling anymore as the inline mode would go away. |
