[xwiki-devs] [Discussion] XEM Workspaces feature integration issues
Hi devs, As part of the process of integrating the Workspaces feature into XEM, I have identified certain problematic integration points. == Context== For those that don't know about the Workspaces feature, here's an initial design page that can still be considered relevant with respect to the current prototype http://dev.xwiki.org/xwiki/bin/view/Design/Workspaces Technically, workspaces are subwikis that can be created by any user (not just admins), that handle only global users (don`t allow local users) and that manage 3 types of workspace/subwiki membership (1. open, 2. on request with admin validation and 3. only on invite). The main wiki contains the workspaces application and is the entry-point from where you can create/browse workspaces. Of course, since it's part of the Wiki3.0 research project ( https://wiki30.xwikisas.com ), the main focus is the user and social interactions. The current prototype ( https://github.com/xwiki-contrib/wiki30 and issue tracker http://jira.xwiki.org/jira/browse/WIKITHREEDOTO ) was built as a forked XEM distribution that comes with 2 features (workspaces and real-time editor). == Issues == For the integration of the Workspaces feature (as a XEM extension), the following problems restrict the Workspace feature from overriding certain XWiki elements while extending them: I) Main Wiki level (for the Workspace Manager Application) 1) Extend XWiki.GroupSheet and templates/getgroupmembers.vm - Add 'follow' action to the group's livetable - Add 'comment'(About) and 'tags' columns to the group's livetable 2) Extend XWiki.XWikiUserSheet - Add 'Workspaces' tab with list of joined workspaces and possibility to list their activity. 3) Extend XWiki.SearchSuggestConfig - Show Workspaces in search suggestions without affecting existing ones. 4) Extend menuview.vm - Show 'Workspace' entry in the 'Add' menu - Show 'Workspace Directory' entry in the 'Wiki' menu - Show 'Main Wiki' entry in the 'Wiki' menu II) Workspace level (for the workspace template) 1) Extend Main.Dashboard - Add new widgets(Workspace Information, Top active users, List of available Apps) without affecting the existing ones. -- There should be a clear difference between Gadgets (contain just the code and are reusable), Dashboard descriptor (for taking care of which gadgets to include and how to do the layout) and the Dashboard macro. To add some gadgets in a dashboard from an application, you should only have to override the dashboard descriptor but not also the existing gadgets. 2) Extend XWiki.AdminSheet - Add 'Workspace' sections in the 'Configuration' category - Replace the section 'Users' from 'Users & Groups' category with a 'Workspace Users' section 3) Customize templates/rightsUI.vm - Hide scope selector for Users in rights UI and use global users as default There is always the option of doing all of the above trough JSX, but that is a far from perfect solution. The general topic of these issues is that applications should be allowed to better extend XWiki and should not be confined to only the "content" section of a wiki page. In particular, almost all of these issues require their own thread and can be considered part of bigger problems, but I think it's a good start to list them here and see what discussions come out of them. The goal is to be able to install Workspace Manager on top of XEM without partially overriding certain pages or touching templates so that the upgrade of the underlying XEM is not affected. Any feedback on these issues is greatly appreciated. Thanks, Eduard
Hi Edy, thanks for the demo yesterday, it was very interesting. Please see my answers below. On Fri, Jul 1, 2011 at 12:40 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
As part of the process of integrating the Workspaces feature into XEM, I have identified certain problematic integration points.
== Context==
For those that don't know about the Workspaces feature, here's an initial design page that can still be considered relevant with respect to the current prototype http://dev.xwiki.org/xwiki/bin/view/Design/Workspaces
Technically, workspaces are subwikis that can be created by any user (not just admins), that handle only global users (don`t allow local users) and that manage 3 types of workspace/subwiki membership (1. open, 2. on request with admin validation and 3. only on invite). The main wiki contains the workspaces application and is the entry-point from where you can create/browse workspaces. Of course, since it's part of the Wiki3.0 research project ( https://wiki30.xwikisas.com ), the main focus is the user and social interactions.
The current prototype ( https://github.com/xwiki-contrib/wiki30 and issue tracker http://jira.xwiki.org/jira/browse/WIKITHREEDOTO ) was built as a forked XEM distribution that comes with 2 features (workspaces and real-time editor).
== Issues ==
For the integration of the Workspaces feature (as a XEM extension), the following problems restrict the Workspace feature from overriding certain XWiki elements while extending them:
I) Main Wiki level (for the Workspace Manager Application)
1) Extend XWiki.GroupSheet and templates/getgroupmembers.vm - Add 'follow' action to the group's livetable - Add 'comment'(About) and 'tags' columns to the group's livetable
2) Extend XWiki.XWikiUserSheet - Add 'Workspaces' tab with list of joined workspaces and possibility to list their activity.
3) Extend XWiki.SearchSuggestConfig - Show Workspaces in search suggestions without affecting existing ones.
4) Extend menuview.vm - Show 'Workspace' entry in the 'Add' menu - Show 'Workspace Directory' entry in the 'Wiki' menu - Show 'Main Wiki' entry in the 'Wiki' menu
I guess it wouldn't be a very clean solution, but until we have implemented IX, would a solution be to add this code to the templates and display the additional features based on a preference in the administration section of the main wiki? Something like "Workspaces is activated YES / NO" looks ok to me.
II) Workspace level (for the workspace template)
1) Extend Main.Dashboard - Add new widgets(Workspace Information, Top active users, List of available Apps) without affecting the existing ones. -- There should be a clear difference between Gadgets (contain just the code and are reusable), Dashboard descriptor (for taking care of which gadgets to include and how to do the layout) and the Dashboard macro. To add some gadgets in a dashboard from an application, you should only have to override the dashboard descriptor but not also the existing gadgets.
2) Extend XWiki.AdminSheet - Add 'Workspace' sections in the 'Configuration' category - Replace the section 'Users' from 'Users & Groups' category with a 'Workspace Users' section
3) Customize templates/rightsUI.vm - Hide scope selector for Users in rights UI and use global users as default
Same as above, is there a way to implement this and let the a dmi choose to activate it or not based on a preference in the main wiki?
There is always the option of doing all of the above trough JSX, but that is a far from perfect solution.
That's clearly not the right way to go. The general topic of these issues is that applications should be allowed to
better extend XWiki and should not be confined to only the "content" section of a wiki page.
That's the vision, but until additional work is done on IX we're stuck with less than perfect ways to deal with this kind of issues. In particular, almost all of these issues require their own thread and can
be considered part of bigger problems, but I think it's a good start to list them here and see what discussions come out of them.
I'm afraid that discussing every individual modification would take a lot of time. Maybe you could do only 2 threads, one for main wiki modifications and one for sub-wikis modifications? The goal is to be able to install Workspace Manager on top of XEM without
partially overriding certain pages or touching templates so that the upgrade of the underlying XEM is not affected.
Right now I think modularizing all of those items is going to be too complicated without the IX infrastructure in place. Thus I think the solution to put it in the default XEM XAR without activating it by default is a good workaround. Thanks, Guillaume Any feedback on these issues is greatly appreciated.
Thanks, Eduard _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Guillaume, Thanks for the reply, see below... On Mon, Aug 1, 2011 at 3:15 PM, Guillaume Lerouge <[email protected]>wrote:
Hi Edy,
thanks for the demo yesterday, it was very interesting. Please see my answers below.
On Fri, Jul 1, 2011 at 12:40 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
As part of the process of integrating the Workspaces feature into XEM, I have identified certain problematic integration points.
== Context==
For those that don't know about the Workspaces feature, here's an initial design page that can still be considered relevant with respect to the current prototype http://dev.xwiki.org/xwiki/bin/view/Design/Workspaces
Technically, workspaces are subwikis that can be created by any user (not just admins), that handle only global users (don`t allow local users) and that manage 3 types of workspace/subwiki membership (1. open, 2. on request with admin validation and 3. only on invite). The main wiki contains the workspaces application and is the entry-point from where you can create/browse workspaces. Of course, since it's part of the Wiki3.0 research project ( https://wiki30.xwikisas.com ), the main focus is the user and social interactions.
The current prototype ( https://github.com/xwiki-contrib/wiki30 and issue tracker http://jira.xwiki.org/jira/browse/WIKITHREEDOTO ) was built as a forked XEM distribution that comes with 2 features (workspaces and real-time editor).
== Issues ==
For the integration of the Workspaces feature (as a XEM extension), the following problems restrict the Workspace feature from overriding certain XWiki elements while extending them:
I) Main Wiki level (for the Workspace Manager Application)
1) Extend XWiki.GroupSheet and templates/getgroupmembers.vm - Add 'follow' action to the group's livetable - Add 'comment'(About) and 'tags' columns to the group's livetable
2) Extend XWiki.XWikiUserSheet - Add 'Workspaces' tab with list of joined workspaces and possibility to list their activity.
3) Extend XWiki.SearchSuggestConfig - Show Workspaces in search suggestions without affecting existing ones.
4) Extend menuview.vm - Show 'Workspace' entry in the 'Add' menu - Show 'Workspace Directory' entry in the 'Wiki' menu - Show 'Main Wiki' entry in the 'Wiki' menu
I guess it wouldn't be a very clean solution, but until we have implemented IX, would a solution be to add this code to the templates and display the additional features based on a preference in the administration section of the main wiki? Something like "Workspaces is activated YES / NO" looks ok to me.
That might be a good idea.
II) Workspace level (for the workspace template)
1) Extend Main.Dashboard - Add new widgets(Workspace Information, Top active users, List of available Apps) without affecting the existing ones. -- There should be a clear difference between Gadgets (contain just the code and are reusable), Dashboard descriptor (for taking care of which gadgets to include and how to do the layout) and the Dashboard macro. To add some gadgets in a dashboard from an application, you should only have to override the dashboard descriptor but not also the existing gadgets.
2) Extend XWiki.AdminSheet - Add 'Workspace' sections in the 'Configuration' category - Replace the section 'Users' from 'Users & Groups' category with a 'Workspace Users' section
3) Customize templates/rightsUI.vm - Hide scope selector for Users in rights UI and use global users as default
Same as above, is there a way to implement this and let the a dmi choose to activate it or not based on a preference in the main wiki?
Already being in a workspace, there's no point at this level to allow further customization. There are no local users in a workspace so it really makes no sense in allowing an admin to set rights for local users.
There is always the option of doing all of the above trough JSX, but that is a far from perfect solution.
That's clearly not the right way to go.
The general topic of these issues is that applications should be allowed to
better extend XWiki and should not be confined to only the "content" section of a wiki page.
That's the vision, but until additional work is done on IX we're stuck with less than perfect ways to deal with this kind of issues.
In particular, almost all of these issues require their own thread and can
be considered part of bigger problems, but I think it's a good start to list them here and see what discussions come out of them.
I'm afraid that discussing every individual modification would take a lot of time. Maybe you could do only 2 threads, one for main wiki modifications and one for sub-wikis modifications?
The goal is to be able to install Workspace Manager on top of XEM without
partially overriding certain pages or touching templates so that the upgrade of the underlying XEM is not affected.
Right now I think modularizing all of those items is going to be too complicated without the IX infrastructure in place. Thus I think the solution to put it in the default XEM XAR without activating it by default is a good workaround.
Yes, that's also what I was thinking about doing... Thanks, Eduard
Thanks,
Guillaume
Any feedback on these issues is greatly appreciated.
Thanks, Eduard _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (2)
-
Eduard Moraru -
Guillaume Lerouge