compare to BrixCMS

Sorry for answering so late, I was traveling around and having a bad internet coverage.

There are some basic differences in how you generate a concrete page in Brix CMS and gidooCMS, especially regarding the dynamic/application elements. Brix CMS has it's own concept called "tiles", that represents dynamic created elements on the webpage and that are part of the markup of a page (as far as I understand). gidooCMS is much more acting like a standard Wicket page/application, but places the CMS content at a special component. The design goal of gidooCMS is, that you can use Java inheritance for overriding behavior. So at deploy time you specifiy what kind of dynamic application content will be displayed. Brix CMS is much more dynamic in this sense, but needs to add it's own concept (the "tiles") to achieve this behavior.

There are also quite big differences in the used markup. gidooCMS is kind of markup-agnostic, just storing XML that is rendered/transformed using XSLT. While you might want to be able to use your own markup or something like Textile, it is perfectly ok to just use XHTML and copy the page content (there is an example XSLT-script for XHTML) and there is even a gidooCMS editor plugin using the WYMEditor (a graphical "what you see is what you mean" XHTML editor). Brix CMS is using it's own templating system that you have to learn first. Since gidooCMS can use any kind of XML, there is a interface to add your own editor "plugin" in case you don't have XML-affine users (as I said, there is already one for XHTML).

So from (my) technically point of view Brix CMS is introducing more of it's own concepts while gidooCMS tries to act much more like a pure Wicket application. So you will actually develop your own CMS using gidooCMS as a "framework" and applying standard Wicket and Java techniques (like inheritance). This means it is not a standalone CMS (take wordpress as an example here) where someone can click together a webpage, but a library (I don't like the word "framework" that much) which implements a lot of the common things you have to do in every CMS system, including a GUI. Since there is a GUI, of course some concepts have to be followed (like the way roles are handled).

Since Brix CMS is developed by some Wicket core developers at a company using this CMS (at least it was that way in the beginning, I don't follow the development here) it was once claimed by them that the professional backing is much better at Brix CMS than with gidooCMS. I have to admit I develop gidooCMS at my spare time, so if you are working for a company that does not like this kind of development you might be better of with Brix CMS.

But I personally like the concepts of gidooCMS more than these of Brix CMS, what is not that difficult since I developed it :)

There are also some differences in the list of pure features. gidooCMS e.g is using the versioning feature of JCR (with GUI support) while Brix CMS is after my knowledge still not providing this. So if you have some "must have" features be sure to check the feature lists.

If you want some deeper information of how to develop your own gidooCMS based CMS please read the developer guide: http://bazaar.launchpad.net/%7Ekrause/gidoocms/trunk/download/head%3A/developing_guide.pdf-20090927182430-q748o99wj6b8rddn-1/developing_guide.pdf There is also a "General Concepts" section which explains the gidooCMS concepts much more concrete. There is also a user guide targeted for the end users (http://bazaar.launchpad.net/%7Ekrause/gidoocms/trunk/download/head%3A/455%405fd3d72d-0931-0410-bb1d-978c1c353e5d%3Atrunk%3Adocs%252Fuser_guide.pdf/user_guide.pdf) which is explaining the concepts and features from the view of an content editor or publisher.

For Brix CMS the Architecture Wiki page (http://code.google.com/p/brix-cms/wiki/Architecture) with its links to the more specific topics might be a good starting point.

It might be a good idea to create a comparison matrix and put it into a FAQ entry. If you have any ideas what to include there I would be glad to hear. Please also note that I'm always happy and open about contributions and co-developers if you want to see some specific features in gidooCMS "upstream".