The XWiki Ecosystem
There arethat are part of the XWiki Ecosystem as shown on the diagram below:
In the sections below we will cover the Architecture for XWiki Products that are based on a Container (i.e. excluding XWiki Eclipse, XWiki Office and XWiki OpenOffice).
XWiki Platform's Architecture
The XWiki Platform offers common APIs and common User interface elements. Products cherry pick elements from the Platform and extend them to create a runnable distribution.
XWiki Platform Core
XWiki Core is a single historic JAR that we are splitting into several distinct modules (see below for modules that have been separated already) and that currently implements the following features:
- Model: All the classes representing the wiki model, i.e. the following notions: Document, Space, Wiki, Classes/Objects, Attachments and more.
- Cache: This is the old cache service, which has been replaced by the new .
- XWiki Syntax 1.0 Rendering: This is the old service for rendering XWiki Syntax 1.0 which we keep for backward compatibility so that existing users can keep using the XWiki Syntax 1.0. For all other syntaxes there's now a new .
- Localization: Handles translations in various languages. A new Localization module is under development that will replace this old module.
- Notification: Handles event regsistration and distribution. For example code can subscribe to receive an event when a new document is created. This is under replacement by the new Observation Module (no documentation yet).
- Exports (PDF, RTF, XAR). In the future this will be done by implementing specific Renderers in the new .
- Security: Authentication & Authorization handling.
- User Management
- ... and more
XWiki Platform Plugins
Plugins that are in their own JAR:
- Exo Platform
Plugins that are still located in the XWiki Core JAR:
- Tag Cloud
- File Upload
- Rights Manager
- User Directory
In addition to the listed plugins above which are created and maintained by the XWiki development team, others plugins have been contributed and can be installed. The full list of available plugins is available on the.
XWiki Platform Modules
A module offers services in a given domain. Modules are the equivalent of Plugins but using the new. Here's the list of implemented modules:
- Office Importer
XWiki Platform Applications
In addition to the listed applications above which are created and maintained by the XWiki development team, others applications have been contributed and can be installed. The full list of available applications is available on the.
As a developer there are various ways to extend the XWiki platform as shown on the diagram below:
- You can write your own application completely and reuse XWiki services such as Rendering, WYSIWYG editor, Rights management, Versioning, etc (see above for the list of Services). If you choose this path you'll need to provide a UI.
- You can use or other Products and extend them by extending the Platform as described in the next section.
Extending the XWiki Platform
The XWiki Platform can be extended by:
- Writing scripts in wiki pages
- Writing Applications (set of wiki pages)
- Writing Plugins in Java
- Writing Modules (ie. set of components) in Java
- Writing new or extending existing ones
- Extending existing Service APIs when they provide extension points. You'll need to check the documentation for the service you wish to extend to know if it provides extension points. For example:
- The provides extension points so that you can add new Syntaxes, new Renderers, etc
- The Security Service provides
Extending XWiki Remotely
If you want to control completely the UI you can call (some) XWiki services remotely using, or .
For other services not offering a remote API you can embed them as libraries (JARs) or create new REST/XMLRPC/GWT extensions.
Specific Architecture items
Understanding how HTTP requests are handled
HTTP Request Analysis
For each HTTP request, during the XWiki initialization phase, XWiki analyzes the URL to extract information from it. For example the http://www.xwiki.org/xwiki/bin/view/Main/WebHome URL generates the following information:
- The URL path contains /view/ and thus the ViewAction.java class is executed (configured in struts-config.xml) and called by the Struts Action, itself configured in web.xml.
- the wiki is the main wiki (since the server name starts by www)
- ViewAction specifies that view.vm will be rendered using Velocity
- the space asked is Main and the document's name is WebHome