July 2015 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] Remove TinyMCE files from the XWiki WAR
by vincent＠massol.net 14 Dec '15

14 Dec '15

Hi devs, Here’s what I commented on https://github.com/xwiki/xwiki-platform/pull/307 : “ Thanks Pascal. I've just noticed that we still bundle TinyMCE in XWiki's WAR. It was probably left for backward compatibility but since it's been like 6-7 years that we've dropped it, I believe we could vote about dropping it from our sources and if someone really needs it they'll still be able to manually install them in their wikis. I'll follow up on the devs list, thanks. “ WDYT? Are you ok to remove it? Thanks -Vincent

9 17

[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] [Proposal] Customized Less Variables on the color editor
by Yacine Kebir 03 Sep '15

03 Sep '15

Hi Devs, I would to propose an improvement for the color theme editor to make it more powerful and flexible. In order to achieve this, I propose to add a new tab "Customized Variables <http://design.xwiki.org/xwiki/bin/view/Proposal/Improvethecolorthemeeditor>" to the editor. This tab would allow us to add more LESS CSS variables and list them in a list We could use this variable in order to add more LESS css rules in the advanced tab and target any area on the platform. http://jira.xwiki.org/browse/XWIKI-12351 WDYT? -- *Yacine KEBIR* Web Designer / Front End Developer yacine.kebir(a)xwiki.com *Mobile: *+213 550 749 033 *Web Site : *www.xwiki.com

2 2

[xwiki-devs] [Iteration][UX] Nested: Livetable
by Ecaterina Moraru (Valica) 03 Sep '15

03 Sep '15

Hi, I've added some ideas on how to display 'Space' column in the AllDocs page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedLivetable Let me know what you think and if there are other ideas. Thanks, Caty

5 17

[xwiki-devs] [Iteration][UX] Nested: Tree Location
by Ecaterina Moraru (Valica) 02 Sep '15

02 Sep '15

Hi devs, By default our Tree is localized in AllDocs. This iteration investigates additional ways to access the current's page position in the hierarchy. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedTreeLocation Thanks, Caty

6 10

[xwiki-devs] [Proposal] Consider Wiki Syntax to be advanced and working in the Nested Spaces paradigm
by vincent＠massol.net 02 Sep '15

02 Sep '15

Hi devs, I had created JIRA issue http://jira.xwiki.org/browse/XWIKI-12304 entitled "Make wanted wiki links create Nested Documents” but I’ve brainstormed with Edy and we don’t agree about it anymore :) We’d like to propose that when the user edits a document using the wiki editor then he’s using the Nested Spaces paradigm (and thus uses “WebHome” to create links to Space homes) and when he edits using the WYSIWYG editor he uses the Nested Document paradigm (no Space concept, only create WebHome documents unless he’s an advanced user). The rationale for this is that a lot of macros accept a reference parameter and I don’t think we should change them to support hiding “WebHome” and do an automatic redirect. That would be too complex. In addition, if you use a script macro, then you’ll also see WebHome mentions. Note that when editing a macro in WYSIWYG editor we’ll need to have a macro parameter displayer for Reference-type parameters to display a tree, so that the non-technical doesn’t have to enter “WebHome”. WDYT? Thanks -Vincent

4 6

[xwiki-devs] [Proposal] Best practice: use References in JS code
by vincent＠massol.net 27 Aug '15

27 Aug '15

Hi devs, In the past we use to pass the wiki, space and page as 3 variables to JS code. For example in dashboard.js we currently have: this.sourcePage = this.element.down('.metadata .sourcepage').innerHTML; this.sourceSpace = this.element.down('.metadata .sourcespace').innerHTML; this.sourceWiki = this.element.down('.metadata .sourcewiki').innerHTML; Now that we need to handle Nested Spaces, it’s more complex and I’m proposing to change our best practice and instead to pass a full reference, as in: this.sourceReference = XWiki.Model.resolve(this.element.down('.metadata .source').innerHTML, XWiki.EntityType.DOCUMENT); More generally the idea would be to do the same as we do in Java code, i.e. to start stopping passing several parameters to functions and instead to use XWiki.EntityReference (or XWiki.DocumentReference, etc). For example for dashboard.js this allows to replace: var link = new Element('a', {'href' : this.sourceURL}); link.update(this.sourceWiki + ':' + this.sourceSpace + '.' + this.sourcePage); With: var link = new Element('a', {'href' : this.sourceURL}); link.update(XWiki.Model.serialize(this.sourceReference)); WDYT? Thanks -Vincent

6 10

[xwiki-devs] [Iteration][UX] Nested: Page Actions
by Ecaterina Moraru (Valica) 25 Aug '15

25 Aug '15

Hi devs, This iterations covers page actions: create, delete, rename, copy, move. Also it contains a proposal on the tree displayer inside page actions. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedActions Thanks, Caty

7 11

[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