XWiki - A brief overview

[Sachin Mittal]

Hi,
I this message is an attempt to give every person understanding about what xwiki is and what it can do for you, whether you are an end user, a business analyst or an independent developer. If you like this article then probably this thread can be sticky or used as a starting point to know xwiki. I have been using xwiki as an independent developer for only couple of months now, so there may be errors and omissions.

1. What is XWiki?
This is a second generation wiki or an applications wiki. In traditional wikis like media wiki one uses these to create and share collaborative content. Xwiki goes one step ahead of that where you can create applications on top of xwiki platform. These applications can in turn help you create and share content and this content can be raw content like in other wikis or be structured content of different types where each having defined set of attributes and defined interfaces to interact with the content.
Next, what type of applications you can create on xwiki?
You can create a simple Create Read Update Delete (CRUD) application to maintain and share some structured data to a rich portal based applications where many such structured objects relate to each other as per the ER diagram and users can use them using rich interfaces defined in xwiki. It all depends on how creative you can get.
In the subsequent sections I would explain on how to map structured entities define interfaces in xwiki.

2. Technology stack behind XWiki?
The application is written using Java and works on any J2EE compliant application server. For most of the deployments tomcat is the best choice.
The core engine is designed on a Struts framework where for every action there are respective Java classes responsible to serve that action.
These core classes interact with the database layer using Hibernate, to store and fetch data.
The front end is written using template engines like Velocity and Groovy.
The application can support number of databases. For a default personal use one can build the application on java based low memory footprint database - Hypersonic. For standard deployments over a lan/wan one can use standard databases likle MySql, Oracle, PostgreSql.
Further application is a meta data driven i.e. apart from the core schema/data which serves as meta data for further data to be created by users it has no other schema/data. It can accept any schema or ER which users would like to store their data into. That is what makes xwiki an ideal platform to build applications. The developers and users can only concentrate on specific functionalities of the application and can leave all the legacy work of storing data to the xwiki platform.
More on this in the next section.

3. How XWiki is presented to us?
The basic deployment of xwiki is to simply unzip the core xwiki war (xwiki-enterprise-web-x.xx.war) in the tomcat container.
This would create a blank xwiki deployment. This blank deployment would be no good for most of us unless we just want to create some wiki pages.
This deployment of xwiki is the core platform. Next step is to create applications on top of it.
The immediate application which we can think of is one that can add/manager users and spaces and their rights. To make our job easier along with the xwiki war the xwiki team has also shipped a xar (xwiki-enterprise-wiki-x.xx.xar) file. A xar file is collection of applications.
With standard xwiki xar we get the following applications:
1. Main 2. Blog 3. XWiki (has the user and space management modules) 4.Sandbox 5. photo
We may choose to import one or all the applications as per our needs. Thus after importing we would have xwiki functional. So up till this point xwiki has served the functionality of what other traditional wikis do. But then this is just a starting point.
I hope up till now following is clear:
We add applications to xwiki to add functionality.
Xwiki team has provided with some default applications to get us started with basic wiki tasks.
In next section I would explain more about application.

4. Understanding applications in XWiki
If you happen to look at the source if xar files these are nothing but collection of xml files.
These xml files contain set of XWiki classes and its attributes and their relationships.
You can also create classes in xwiki which would map to the entities of your applications and relate them as per your business needs. Once you are done you can export the page or space and you would have your application ready (Mostly application are packaged as a space. Say panels application is under a panels space.). Then this application can be imported to any xwiki deployment.
More on this can be found under DevGuide and Applications section on xwiki platform on xwiki.org
XWiki team have themselves created many applications few gets shipped with standard xar file (as described above), few are part of core platform and can be downloaded and imported from xwiki.org or can also be built directly from the source (if you like me are in habit of building xwiki always from source).
One can import and study them to know how to create simple to complex applications.
I would touch on applications once again in the end.

5. Understanding User Interface in XWiki
The user interfaces are defined under skins. The skin can be found under webapps/xwiki/skins directory. Default and most supported skin is albatross. A skin is a set of velocity templates, javascript and css files. You can do many things with the UI:
1. Say you like to change the presentation of objects of particular class you define in some application. Then this can be done by altering the velocity code in the template of the class.
2. Say you like to change the overall look and feel of the application. Then the place would be to start altering the velocity templates/js files/css files under the albatross skin. Once you have done and tested the needed changes the same skin can be renamed to the bird of your choice.
More on skins can be found under the AdminGuide on XWiki Platform on xwiki.org.
Before I move forward I would like to explain how UI of xwiki is rendered.
Whenever any xwiki action is requested it calls set of velocity pages (.vm files) responsible for generating and rendering the UI content for that action. A velocity page may further include other velocity page, and this way a hierarchy of  pages is established. Each vm page can access some of the core objects of xwiki. More on these objects can be again found in the DevGuide.
Thus vm page would access these objects, fetch the relevant content and display them as they are to be rendered on the browser.
So you can see that this gives one lot of flexibility on the UI side. I can do many things, change-rearrange the hierarchy, remove the pages whose content I don't want, re arrange the content in a page.
I can even add the js files of my favorite ajax toolkits and now I have the same content generated by vm templates rendered by my ajax widgets thus giving a whole new look.
As mentioned above that these vm files access core xwiki objects. You can also make them access your own objects. This can be done by defining plugins which takes xwiki to even a further level. More on this in next section.
Last point I would like to mention is that in order to modify and alter the skins vm files we have to know that what are the vm files and in what order they are called on each user action. I don't have a document answer to this, but since I build xwiki from source and am able to add breakpoints to find the same information. Perhaps this could be done by some log settings.

6. Extending XWiki and wrap up
I hope by now following is clear:
1. Xwiki presents us with core platform.
2. It can be extended by adding applications.
3. The look and feel can be altered to a great extent by modifying vm files.
4. It can be further extended by adding plugins which introduces objects in xwiki engine.
5. To help us xwiki has created and supports some applications and plugins as part of their source.
If you happen to checkout the source of xwiki you would notice that it has been arranged pretty intuitively. It has the following top level structure (important ones):
1. xwiki-platform-applications
    - the set of applications xwiki built
2. xwiki-platform-core
    - the core platform
3. xwiki-platform-plugins
    - the set of plugins xwiki built
4. xwiki-platform-web
    - the standard UI which contains skins and velocity templates
5. xwiki-product-curriki
    - their curriki product, which is built on core platform.
    - this would further have its own set of plugins, applications and skins.
6. xwiki-product-enterprise
    - the core xwiki product something to start with for standard xwiki deployments
7. xwiki-product-enterprise-manager
    - the enterprise manager product
8. xwiki-product-watch
    - their watch product, which is built on core platform.
    - this would further have its own applications and skins.
Idea of presenting this structure here is that if you want to build rich applications on xwiki and package them as product on top of xwiki platform, these would give you some insight. While building the product you can choose from the set of applications and plugins already built by xwiki team which are part of core or part of specific product. You can also start with skin you like and modify as you want.
note: this section is specially for developers who want to create products and would like to choose xwiki as the platform. Knowledge of technology stack used in xwiki is advisable and also try to build xwiki from source, to give you greater flexibility and control.
Lastly I would touch on plugin section of which my knowledge is only theoretical has I am yet to create a plugin. You can find information on plugin architecture on xwiki DevGuide section CreatingPlugins. You would need plugin to do some custom task that can be called via action from a velocity page. Say I have to create a workflow for my class. Upon state change some custom process needs to be invoked (like send of email), I can do that in my plugin and when user changes the state then I invoke the plugin from my vm file.



Thanks
Sachin