xwiki-devs August 2015

xwiki-devs@xwiki.org

15 participants
43 discussions

[xwiki-devs] The future of the Spaces macro in the context of Nested Spaces/Documents

by Marius Dumitru Florea

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

9 years

[xwiki-devs] Angular: good or bad in the end?

by vincent＠massol.net

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

9 years

[xwiki-devs] [Proposal] Canonical Javascript/CSS code organization

by vincent＠massol.net

Hi devs, I’d like to propose the following official future organization for our javascript/CSS code. Note1: When I say “javascript” below, it should be understood as js + css (possibly less too). Note2: I started writing this email and then I realized Marius had already implemented it for 2 Extensions/Modules: the Platform Tree and the Platform Job modules. I was happy to discover this since it validated the idea I had ;) Maybe Marius has already sent an email to propose all this, in which cas I apologize for the duplication! So here’s the idea: * We should locate Java, REST and Javascript APIs in the Extension they relate to. For example the Model Module should hold the current Reference API but also the Javascript API to create, resolve and serialize references (i.e. what’s currently in entityReference.js). * Thus when an Extension adds or modify its Java API, it should keep in sync the other APIs too. And these APIs should be made available to the XWiki runtime only when those Extensions are loaded into the runtime. * The Javascript APIs should be packaged as webjar resources inside the JAR for the Extension (i.e. located in META-INF/resources/webjars/* in the JAR). Note: An Extension could deliver a singe JAR or several if we wish to separate the Java API from the Javascript API for example (this is what we currently have for the Platform Job and Platform Tree Webjars for ex). * The Javascript APIs should be declared using requirejs, using a define(), as in: define(['jquery', 'JobRunner', 'jsTree', 'tree-finder'], function($, JobRunner) { … } Note: In order to pass simple names to the define() and handle conditional minification, Marius has created a require-config.js in the tree webjar’s module: /*! #set ($minified = '.min') #if ($request.minify == 'false') #set ($minified = '') #end */ require.config({ paths: { jsTree: "$!services.webjars.url('jstree', 'jstree.min')", JobRunner: '$!services.webjars.url("org.xwiki.platform:xwiki-platform-job-webjar", "jobRunner${minified}")', 'tree-finder': '$!services.webjars.url("org.xwiki.platform:xwiki-platform-tree-webjar", "finder${minified}")', tree: '$!services.webjars.url("org.xwiki.platform:xwiki-platform-tree-webjar", "tree${minified}")' }, shim: { jsTree: { deps: ['jquery'] } } }); * The Javascript APIs should be accessed using requirejs, using a require(), as in: require(["$!services.webjars.url('org.xwiki.platform:xwiki-platform-tree-webjar', 'require-config.min.js', {'evaluate': true})"], function() { … } Note: We’ll need to better handle the minification part in this example so that it’s optional and can be controlled by minify=true|false in the query string, but that’s easy to do. * Unit tests should be provided using Jasmine inside the Extension * The requireJS deps should be kept in sync with the Maven deps. WDYT? If we agree about this then I’m proposing that we document it in the DevGuide at http://platform.xwiki.org/xwiki/bin/view/DevGuide/FrontendResources (which will need to be rewritten as it’s currently aging). The next step would be to find a way to move all our JS code under requirejs. I’ve been researching this but I’m far from being able to propose a solution at this time. I’ll need to brainstorm with our JS experts ;) Thanks -Vincent

9 years

[xwiki-devs] [Brainstorming] Should we stop setting the parents when creating new pages + mandating parents in the build

by vincent＠massol.net

Hi devs, When we create a new page through Add > Page (for example) we are still setting the parent ATM, even though it’s not used by default in the breadcrumb or elswhere. Question 1: do we still want to set it or should we stop doing that when core.hierarchyMode=reference? Question 2: do we still want to enforce having a parent set in our build? My preference would to not change any in the 7.x cycle (i.e. keep setting the parent when creating new pages and keep enforcing parents in the build). The rationale is that: * 7.x is a transition cycle for Nested Spaces/Documents so it’s good to observe how users are using them * We should not use Nested Documents in our apps in the 7.x cycle as this would cause potential breakages in existing extensions since we would change location of wiki pages. IMO we need to implement aliases before we start doing so, but not before 8.x. WDYT? Thanks -Vincent

9 years

[xwiki-devs] [Proposal] Document Aliases

by vincent＠massol.net

Hi Devs, I’ve started a proposal at http://design.xwiki.org/xwiki/bin/view/Proposal/DocumentAliases for having Document Aliases. WDYT? Note that it should be pretty easy to implement in the way I described it and using Idea 3 for the UI. Thanks -Vincent

9 years

[xwiki-devs] [ANN] XWiki 7.1.2 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 7.1.2. This is a stabilization release that fixes important bugs discovered in the previous 7.1.1 version. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki712 The following people have contributed code to this release: Ecaterina Moraru (Valica) Eduard Moraru Guillaume Delhumeau Jean SIMARD Thomas Mortagne Vincent Massol Thanks for your support -The XWiki dev team

9 years

[xwiki-devs] [Proposal] Migrations for Extensions

by Marc Sladek

Hi XWiki devs I'd like to propose the following enhancement for the XWiki Migration Manager. This is the follow up proposal to this discussion <http://lists.xwiki.org/pipermail/devs/2015-February/058396.html>. The current idea is to merge the concepts of the Extension Manager and Migration Manager. Extensions should be able to provide individual data migrations to add the possibility of altering data relevant to this extension. These should be executed after installation or upgrade of an extension. Currently, the Migration Manager (still residing in the oldcore) does not support external migrations and only a version number for XWiki migrations is stored in the database. It has to be refactored (to it's own module?) and requires the functionality to store multiple version numbers with specific identifiers in the database for versioning migrations for individual extensions. We at the celements team <http://www.celements.ch/Home?language=en> have an interest in this functionality and are willing to carry and implement it. If you agree with the basic idea, I will start a design proposal document with more detailed information and possible challenges on http://design.xwiki.org WDYT? Marc synventis gmbh

9 years

[xwiki-devs] [Idea] Create a www.ihatexwiki.org/net web site

by vincent＠massol.net

Similar to http://www.ihateeclipse.com/ We could easily create that using XWiki itself. The idea would be to gather feedback from users about the most irritating things to fix in XWiki. A good idea for a hackathon or a 20% time project IMO... Just an idea... -Vincent

9 years, 1 month

[xwiki-devs] [ANN] XWiki 7.2 Milestone 2 released

by vincent＠massol.net

The XWiki development team is proud to announce the availability of XWiki 7.2 Milestone 2. The focus of this release was on fixing issues introduced in 7.2 Milestone 1 with the new Nested Document/Nested Spaces features and to continue adding support for this feature in various existing features (using a tree for the Import UI instead of a list, new DB table to have performant Space queries, start of Nested Spaces support in the XWiki JS APIs, etc). Another major feature added was the new Script permission to allow forbidding Script execution to specific Users or Groups. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki7.2M2 The following people have contributed code to this release: Thomas Mortagne Vincent Massol Caleb James DeLisle Eduard Moraru Guillaume Delhumeau Marius Dumitru Florea Sergiu Dumitriu Thanks for your support -The XWiki dev team

9 years, 1 month

[xwiki-devs] [Proposal] New location for functional tests not requiring wiki pages: in the skin module

by vincent＠massol.net

Hi devs, I’ve brainstormed with Thomas and we’ve discussed where to put functional tests such as test that verify that page creation from the UI works (i.e. that test the create vm and the oldcore java action in this case). We’re proposing to put those tests (which are currently located in enterprise tests) under xwiki-platform-flamingo-skin, i.e. to assimilate those tests as functional skin tests. In order to do this I’ll create: xwiki-platform-flamingo |_ xwiki-platform-flamingo-skin |_ xwiki-platform-flamingo-skin-resources (—> zip) |_ xwiki-platform-flamingo-skin-test (functional tests) |_ xwiki-platform-flamingo-theme |_ xwiki-platform-flamingo-theme-bootswatch (XAR) |_ xwiki-platform-flamingo-theme-ui (XAR) |_ xwiki-platform-flamingo-theme-test (functional tests for Theme UI) WDYT? I’m going to start moving and splitting the current CreatePageTest into 2: * the tests that use Template Provider will go in platform-administration-tests * the tests that verify simple page/space creation will go in xwiki-platform-flamingo-skin-test Thanks -Vincent

9 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs August 2015