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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
