On 05/21/2013 05:22 PM, Beebe, Mary J wrote:

Xwiki developers,

Our company develops wikis. We set up the core wiki, and then write extensions to add specific tools depending on the subject of the wiki . All of our wikis have been developed with the MediaWiki platform, which is written in PHP and prefers the mySQL database. We need to convert over to a Java and Oracle solution; XWiki is a contender for us.

To help us decide on xWiki, Do you mind answering a few questions for us such as the following?

1. One advantage of wikis for us is the revision history, fast creation of content, media uploads, and the user management. Are these things solved well with xwiki?

Yes, see [1-4].

2. We need to add some custom tables to the wiki database and then save to those tables from a page form. Is that possible?

Well, XWiki's main feature is that it allows to create applications around structured data. So it does allow creating custom forms, and the data entered through those forms will be stored in the database. However, by default XWiki maps this custom data to predefined tables, offering powerful APIs for accessing it [5], several ways to query it [6], and even an easy-to-use application wizard [7]. You might be interested in [8] as well. But it is possible to use your own custom tables, although not quite as easy as using XWiki's data model. One way is to continue to use Hibernate and add new types of entities, like [9] is doing. Another way is to bypass the XWiki storage completely and use SQL/JDBC directly from a Java component. This requires the most amount of extra work.

3. We need to develop forms for particular categories. The fields within the forms will be saved to your tables and our custom tables. Is this possible?

See the answer for 2. In short, yes, but with some custom code.

4. It looks like xWiki has components. We are just starting to experiment with your components. Are they helpful with your product?

Of course. We're trying to move as much code as possible from the monolithic old core to clean, modular components. Perhaps what's more interesting for you is a special kind of components, ScriptService [10]

5. Do you have hooks in the code or other possibilities to extend code without changing it?

What kind of code? There are many kinds of extensions that XWiki supports, from replaceable Java components to JS/CSS skin extensions and UI extension points.

6. Is it possible to change core code?

Yes. Since XWiki is open source, you can fork it on GitHub and build your own patched jars. Also, since several parts of XWiki are implemented as components, they can be replaced with your own version of those components.

User mark up differences between your xWiki and mediaWiki is not a big factor for us.

Thanks,

Mary

[1] http://platform.xwiki.org/xwiki/bin/Features/VersionControl [2] http://platform.xwiki.org/xwiki/bin/Features/PageEditing [3] http://platform.xwiki.org/xwiki/bin/Features/Attachments [4] http://platform.xwiki.org/xwiki/bin/Features/UsersAndGroupsManagement [5] http://platform.xwiki.org/xwiki/bin/DevGuide/ [6] http://extensions.xwiki.org/xwiki/bin/Extension/Query+Module [7] http://extensions.xwiki.org/xwiki/bin/Extension/App+Within+Minutes+Applicati... [8] http://platform.xwiki.org/xwiki/bin/Features/Forms [9] http://extensions.xwiki.org/xwiki/bin/Extension/Activity+Stream+Plugin [10] http://extensions.xwiki.org/xwiki/bin/Extension/Script+Module -- Sergiu Dumitriu http://purl.org/net/sergiu

Here is feedback from a more "consumer" approach, as a developer of curriki.org.

Our company develops wikis. We set up the core wiki, and then write extensions to add specific tools depending on the subject of the wiki . All of our wikis have been developed with the MediaWiki platform, which is written in PHP and prefers the mySQL database. We need to convert over to a Java and Oracle solution; XWiki is a contender for us.

To help us decide on xWiki, Do you mind answering a few questions for us such as the following? 1. One advantage of wikis for us is the revision history, fast creation of content, media uploads, and the user management. Are these things solved well with xwiki?

While media-upload has been insufficient for us, because re-encoding is necessary, the other features (revision history, fast creation of content, uploads, user-management) have been taken up directly out of xwiki and they work well even with a big scale (400'000 members, 40'000 learning resources).

2. We need to add some custom tables to the wiki database and then save to those tables from a page form. Is that possible?

See Sergiu's answer here. As a developer that made other web-server-softwares before I can say that within xwiki, it's not hard to circumvent some of xwiki if you do not want to use it, from the request/response processing until the database. The fact that a lot of code can be written and hot-loaded makes it really nice to develop in team.

4. It looks like xWiki has components. We are just starting to experiment with your components. Are they helpful with your product?

There used to be plugins and they were very often used in Curriki. Components are similar to my taste, with the added advantage of the exchangeability thanks to the weaker loading.

5. Do you have hooks in the code or other possibilities to extend code without changing it?

Lots

6. Is it possible to change core code?

User mark up differences between your xWiki and mediaWiki is not a big factor for us.

There's quite a few other pearls in the xwiki eco-system. One of them is the WYSIWYG editor which has declarative macro-based extensibility and can also be nicely extended thanks to engineering done in Java (it is GWT based). Another is the bet that syntax based editing does not need to be an enemy of wysiwyg editing... the editor just inserts where it needs. The many extensions are also a nice set of pearls! Paul