June 2015 - xwiki-devs@xwiki.org

[xwiki-devs] [Idea] Page Administration
by Ecaterina Moraru (Valica) 19 Nov '15

19 Nov '15

Hi devs, So this proposal appeared in some of my proposals but right now I created a proper Proposal/Idea mail for it. It's about having an 'Administer Page' section in the menus, similar to the 'Administer Wiki' and 'Administer Space' functionality. The 'Administer Page' will be accessible to global admins, page creators and users with (edit?/admin?) rights for the page. >From what we currently have implemented it should contain the 'Rights Editor' (?editor=rights) at page level. In the future we could make 'Presentation', 'Page Elements' or 'Panel Wizard' to be more granular and be set at Page level (have different panels and style for just one page). Some screenshots at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PageAdministration Thanks, Caty

5 9

[xwiki-devs] [UX][Consistency][Vote] "Page" vs. "Document" consistent naming
by Ecaterina Moraru (Valica) 09 Sep '15

09 Sep '15

Hi, We are using mixed naming when referring to a document/page, not only on different pages, but also in the same context (Rename step for example). There is also an issue referring to this problem XWIKI-5401<http://jira.xwiki.org/jira/browse/XWIKI-5401>and we need to find an answer in order to move forward consistency. So the question is which version we prefer: "Page" or "Document" ? I'm voting +1 for "Page". "Page" is more used IMO, especially in the "Space"/"Page" context. "Page" is more general than "Document" and better fitted for a platform that encapsulates all kind of content (not just documents). Please cast your vote. Thanks, Caty

10 14

[xwiki-devs] The future of the Spaces macro in the context of Nested Spaces/Documents
by Marius Dumitru Florea 24 Aug '15

24 Aug '15

Hi guys, The wiki home page displays, by default, the list of spaces that exist in the wiki (hidden or not, depending on the user profile settings). This is done using the http://extensions.xwiki.org/xwiki/bin/view/Extension/Spaces+Macro . As we have started to work on adding support for nested spaces/documents, we need to review the purpose of this macro. Is it still relevant to display a list of spaces when there is a tree hierarchy? It only makes sense if you want to display just the list of direct children of a given node. I see the following options: (1) Display the list of top level nodes (space/document) on the wiki home page. No tree. The rationale is that loading the tree (even if done lazy) is more expensive that displaying a static list of links. For this we can extend the Spaces Macro with a parameter to specify the parent node. When this parameter is not specified the macro will list the top level nodes. (In the context of nested documents we could introduce a new macro Document List instead) (2) Display the tree hierarchy on the wiki home page, using http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro .Of course, the tree will be lazy loaded, and only the top level nodes are displayed initially. If we do this then we can probably deprecate the Spaces Macro and advice the users to use the Document Tree Macro instead. WDYT? Thanks, Marius

5 13

[xwiki-devs] Angular: good or bad in the end?
by vincent＠massol.net 23 Aug '15

23 Aug '15

Some stuff to read to verify if there’s any truth in that, in the context of XWik project adoptiong Angular (or not): https://gist.github.com/tdd/5ba48ba5a2a179f2d0fa Thanks -Vincent

5 6

[xwiki-devs] [Iteration][UX] Nested: Add action
by Ecaterina Moraru (Valica) 06 Aug '15

06 Aug '15

Hi, With the introduction of Nested Documents and the removal of global menu, we are confronted with the problem of moving and redefining the content of 'Add' action. The iteration experiments multiple possible alternatives of the 'Add' location and look, read more http://design.xwiki.org/xwiki/bin/view/Proposal/NestedAdd My recommendation is to: - Move the 'Add' (page/child) button inside the content area and display it as a button; - Move the 'Add wiki' functionality inside Drawer + Wiki Index; - Select the page template from the dedicated create action page; Feedback is welcomed. Thanks, Caty

5 8

[xwiki-devs] [Iteration][UX] Nested: Drawer
by Ecaterina Moraru (Valica) 30 Jul '15

30 Jul '15

Hi, One design problem we face with the introduction of Nested Documents is that the current global menu is not extensible anymore to support large hierarchies. Also if we hide/deprecate the Space concept we need to find a solution to transfer all the current navigation and actions in another component. This proposal covers the introduction of a Drawer menu that will contain: Profile, Wiki Actions and Wiki Navigation. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedDrawer Feedback is welcomed. Thanks, Caty

5 10

[xwiki-devs] What do we do with space and page templates in ND?
by Eduard Moraru 01 Jul '15

01 Jul '15

Hi, Now that we are moving to Nested Documents, there is the question of what do we do with the existing space and page templates[1]? How do we (still) display them? In the new create UI we will be showing just the option to create a Nested Document, but for advanced users, we might also show the option to create a terminal document (NS-style i.e. document in a space). Since a ND translates to a space WebHome in the NS approach (or previous approach), we could reuse any existing space templates and display them instead of page templates. Existing page templates were built with the NS approach in mind and I am concerned that, until the app that provides them does not migrate them to space templates (i.e. ND-compatible), we risk breaking their functionality (?). This might now be valid for page templates manually created by the admins that might have no issues since they are content focused and not processed by any application. Until they are migrated, we could just show page templates only when creating terminal documents, as an advanced user. So the options I see are: 1) Show both space and page templates when creating ND and only page templates when creating terminal pages, hoping most of them will work most of the time. 2) Show only space templates when creating ND and only page templates when creating terminal pages, but risk hiding a lot of useful page templates from regular users which would work most of the time. My +1 goes to 1). WDYT? Thanks, Eduard ---------- [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Administration+Applica…

6 5

[xwiki-devs] [VOTE] Summary: NS, ND, Parent/Child
by Ecaterina Moraru (Valica) 01 Jul '15

01 Jul '15

Hi devs, So after discussing the topic of Nested in several mails, we need to reach a conclusion in order to start implementing. There are several open questions that I will summarize. Please cast your votes in order to advance on some topics and maybe discover what we still need to agree on. Q0. **Nested Spaces in model** No matter the UI decisions we still need to take, we are implementing Nested Spaces for 7.2 roadmap. The future is still uncertain regarding changing the model to accommodate Nested Documents, since we can simulate ND using NS. Q1. **NS vs ND in the UI** Q1.1 The majority agreed that since the final purpose are ND, we should display ND in the UI, since it simplifies the mental model of the user. This implies removing the Space concept from the UI. Q1.1.1 A consequence is hiding the 'WebHome' name in the UI. Q1.2 Although the default should be ND, the question is if we want to give the option to display NS in the UI. This would be implemented as an advanced and technical option. The main problem is that we might need to provide UI alternatives for several components (menus, create step, etc.) Q2. **Parent/Child** Q2.1 Deprecate the notion of Parent/Child. Q2.1.1 Provide a migration to transform the relation into NS/ND. Problem: the old URLs[A] (bookmarks) are broken + the user is stuck with long URLs[B] if he wants to keep the hierarchy. Additionally we might need to provide an extension/configuration to transform into short URLs [B -> C]. Q2.1.2 Don't migrate: the parent/child hierarchy will be lost but the old URLs[A] (bookmarks) will be kept. The user needs to use NS/ND to create hierarchies. Q2.2 Don't deprecate the notion of Parent/Child. Q2.2.1 Provide a configuration in the Administration to switch the breadcrumbs between displaying Parent/Child or NS/ND. We might need to provide UI alternatives for several components (tree, breadcrumb navigation, create, etc.) Please cast your votes / add comments. Thank you, Caty

8 21

[xwiki-devs] XWiki's architecture diagram
by Ghosh, Amrita 25 Jun '15

25 Jun '15

Is there any XWiki's detailed architecture diagram documented somewhere? If yes, then can you please point me to this document? Thanks, Amrita

2 2

[xwiki-devs] [Proposal] Object addition/removal/update shouldn't change content author
by Vincent Massol 23 Jun '15

23 Jun '15

Hi, According to the javadoc in XWikiDocument: /** * The last user that has changed the document's content (ie not object, attachments). The Content author is only * changed when the document content changes. Note that Content Author is used to check programming rights on a * document and this is the reason we need to know the last author who's modified the content since programming * rights depend on this. */ private DocumentReference contentAuthorReference; This means that objectadd or objectremove actions shouldn't change the content author as they do now. I'm proposing that we fix this. Do you see any issue? Thanks -Vincent

7 11