5 Aug
2011
5 Aug
'11
4:32 p.m.
Hi Guillaume,
Thanks for the reply, see below...
On Mon, Aug 1, 2011 at 3:15 PM, Guillaume Lerouge <guillaume(a)xwiki.com>wrote;wrote:
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.
Yes, that's also what I was thinking about doing...
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 <enygma2002(a)gmail.com>
wrote:
That might be a good idea.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs