21 Sep
2011
21 Sep
'11
9:41 p.m.
Hi Eddy and all,
On Sep 21, 2011, at 6:43 PM, Eduard Moraru wrote:
Hi devs,
As part for the 3.2 Roadmap, the plan for the workspaces feature was to add
some hooks into the platform that could accept a workspaces extension if an
admin decided to install it.
Without adding these hooks, there currently isn`t any mechanism (like
Interface Extensions, but not limited to that) that allows a simple
application to modify whatever it wishes (like user profile sections,
administration sections, top menu, etc.) so I went ahead and added some code
into the platform that executes only when the workspaces extension (wiki
pages and component/service) is installed.
I don't like this too much for 2 reasons:
1) the workspaces app is not part of the platform ATM. It would be like someone we
don't know coding an application and sending us a patch to modify the platform code to
test if his own personal app is installed or not
2) it keeps adding kludges instead of finding a real solution
To help with point 1), we could vote the fact that we're ok to have workspaces in the
platform but that doesn't solve 2).
We could look at it point by point and find a solution for each point.
IMO ATM you should use jsx to add those entries so that no change is required in the
platform. I know some of you don't like this solution but IMO the best right now when
the application is not part of the platform.
Then we need to open a discussion for adding extension points for each location where you
need it.
One solution would be to use XClasses to provide extension points.
Point 1: Ability to add User tabs. There are several ways in which this can be achieved.
Example solution: Introduce a UserTabClass and add as many tabs as there are UseTabClass
objects in the wiki
Point 2: Ability to add menu entries in the top level menu.
Example solution: Have a MenuEntryClass and a MenuItemEntryClass, each having 2 fields:
one field for the menu entry name and one for the position. The construct the menu
dynamically
The issue with these solutions is performance. A solution would be to add a module and
have java listener listening to object changes + an API to return the data. However this
maybe slightly too complex. BTW it could be interesting to offer a generic script service
to do this (the idea would be to offer an active cache that would refresh when an XObject
is updated).
Of course another solution would simply be to bite the bullet and start implementing IX…
;) (I need to read again Sergiu's design doc about it since I have forgotten how
Sergiu planned to implement it)
Any other idea?
Thanks
-Vincent
I`ve created http://jira.xwiki.org/browse/XWIKI-6991 with some details about
what I have done and made a pull request at
https://github.com/xwiki/xwiki-platform/pull/24 since I did not want to rush
at applying the changes without running them by you guys.
I`ve broken the issue down to subtasks with separate commits to make the
review easier.
There currently is a demo server for the workspaces feature at
http://wiki30-demo.xwiki.com but I will have to update it tomorrow with the
latest version. Not much changed, you can see the visible changes in the
specific jira subtasks (screenshots).
The goal would be for this to make it into 3.2 so that people could then
install (the soon to be released) workspaces extension and try it out.
Please take some time, if possible, to look over the proposed changes and
spot any problems.
Thanks,
Eduard