Wow, seems you spent some time on our code, what was your login in Forum?
Nevertheless, some parts have been added to the wiki documentation so I will detail your comments.
I did not mean learning curve for used specs, I mean eXo itself. As you rightfully noticed there is interest from OEM, so it means that we need to change/modify/add features to eXo. Some kind of cookbook could greatly help here.
We tried to provide such things in the wiki. If you see that you would like some tutorials or information that are not yet in feel free to register and edit the wiki, we will fill the blank pages.
-how-to programmatically add new user;
-how-to check permissions;
This information is available in two wiki pages that describe the Organization service :
http://www.exoplatform.com/xwiki/bin/view/Main/Organizationservice and how to map it to your own model :
http://www.exoplatform.com/xwiki/bin/view/Main/customizeorganizationI agree that there is no code example :) we though that UML would be enougth. If you don't think so, tell us and we will add the code. Also note that you can always find the code in our unit test ;).
-how to create own navigation/menu portlet;
This is missing in the tutorial you are correct I have added an new page in wiki
http://www.exoplatform.com/xwiki/bin/view/Main/SomeHow-tos for it.
Content management: creation of a page that is based on simple HTML is unnecessary complex;
In RC3 we have added template for page layout creation. That may be a good idea to do the same for basic pages with only HTML portlet on it. I add it to our TODO list and see what teamates think.
External portal configuration management for user groups, here I mean that for my use cases it would be nice if I could define and then change group based portal configuration. At this moment user creation listener can copy group configuration as new user configuration, and then it is saved as user configuration and can be edited on per user basis. But I do not want users in a ‘dumb’ group be able to edit their configuration, I want them to use common configuration for the group, also as admin I want to change that group configuration at runtime (even server restart is OK). It seems to be possible with eXo, but not very obvious how to do it.
Yes this is possible both at the role and membership level (you will see why memberships are needed ;) ). It is explained in the last section of
http://www.exoplatform.com/xwiki/bin/view/Main/portalconfigurationIn one case a user with J2EE role will import the portal layout from a define group portal.
In the other case, a user that has a "membership" in a group will import the portal layout.
In both cases user will not be able to modify the portal layout.
You have to choose one behavior for you portal. Note that you are not forced to use memberships but you can stick with J2EE roles here :)
Another thing is development convenience, which is great part of learning curve: it takes about 12 minutes to compile eXo platform, and Maven reactor spits out some frightening messages and then seems to freeze, but eventually wakes up and builds project fine. Such long cycle might be prohibitive as a newcomer wants to try little things here and there, but it is too frustrating to wait 12 min + time to restart container to see results.I am sure there are some ways to address this.
Well to build all with test it takes 6 minutes on Tuan's computer and 4 minutes without test. But that is not an argument I agree, not everybody can buy what Tuan bough last week :)
But note it is possible to do incremental build as described in
http://www.exoplatform.com/xwiki/bin/view/Main/buildinstructionsIt higly improves development process ;) Some people also use eclipse to build, run test and even debug. As a side note, debugging into eclipse will be added in next plugin version.
There was no Postgres integration in the code, even it seemed as it was there.
Strange was added for one of our OEM in RC2, maybe you tried with RC1.
I tried to add it, but have discovered that it is not very straightforward with no apparent reasons ( basically the same settings need to be specified in two places ). Separation between eXo data source and WF data source might be fine, but for simplicity sake WF should use eXo ds as a default and not require a separate config.
I would say that adding a DB support is quite easy actually (described in
http://www.exoplatform.com/xwiki/bin/view/Main/databaseconfiguration).
There is a reason why workflow datasource and exo datasource are separated. Indeed our workflow service is based on JBPM 2.0 beta 2 and until JBPM get at least RC1 we prefer to split the database to ease upgrades...
Overall I have found process of obtaining services somehow vague, might be because lack of documentation, but I remember that after obtaining some references to bases services I did not find methods I would expect there like permission checks.
All service manipulation and theory is described in our user manual at
http://www.exoplatform.com/xwiki/bin/view/Main/developermanualLookup a service is mainly done using either dependancy injection (constructor one) or the service locator design pattern (refer to Martin Fowler article for more information on those definition....but I guess you are familiar with that :) )
If you need more information ping me
And your permission model is not quite straightforward, IMO membership is not necessary and simple role based schema could work pretty well for portals. Could you please provide an example where membership is convenient or necessary to use?
Sure :)
First note we don't force you to use membership, if you don't need them just stick with JAAS and J2EE security roles.
The problem of J2EE roles is that it is dealing with organization crosscutings roles and that many real organization relashionships do not fit into that model. Hence it is difficult with roles to model that user U has such role R in Group G, and that is exactly why we added memberships that are simply defining relations between user and groups.
They are many use cases and the most common one is what we call "community injection". We use memberships to mount some group node tree inside a user tree. With that method it is possible for a user to view many navigation tree of several groups if he has the correct membership of the group.
Hope this help.
Benjamin
