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
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
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
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
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
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
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
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
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