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
--
View this message in context:
http://www.nabble.com/XWiki---A-brief-overview-tp15116968p15116968.html
Sent from the XWiki- Users mailing list archive at
Nabble.com.