July 2011 - xwiki-devs@xwiki.org

[xwiki-devs] about login and logout using XWiki REST API
by Jun Han 25 Aug '11

25 Aug '11

Dear all, I am on the way of replacing the xmlrpc implementation of RemoteXWikiDataStorage implements IDataStorage {}. One question is about how to implement login and logout functionality via REST API. From REST API document, users can be authenticated via something like: 1. XWiki session 2. HTTP Basic Auth. HTTP basic auth can be implemented via adding HTTP header to the HTTP request, then XEclipse can display Xwiki Resources by parsing the response. Therefore, do we need to implement login and logout methods? Best regards Jun Han

9 65

[xwiki-devs] The plan of GSoC project "Auto-completion in content editors" (7.25 - 7.31)
by 许凌志(Jamesxu) 08 Aug '11

08 Aug '11

Hi, Last week I have done following things: 1. Refine the suggest lucene service, and a query "media", which have two options: "xml" and "json", each gives the xml and json results. 2. Thanks Eduard, Marius and Sergiu, with their help, I finnally find the right search queries of suggest lucene service to get right suggestion results. 3. The autosuggestion can use the real datas from xwiki now. In this week, I am going to do the following things: 1. Implement the whole context for link suggestion, include "attach:", "@", "." and "||".( I have done some designations, but still want to discuss with mentors) 2. Consider to implement the ctrl+space to re-open the suggestion box according to the different contexts of link suggestion.(after the 1 is finished) -- Best wishes, 许凌志(Jame Xu) MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University Department of Computer Science and Technology, Xi’an Jiaotong University

2 8

[xwiki-devs] [Discussion] XEM Workspaces feature integration issues
by Eduard Moraru 05 Aug '11

05 Aug '11

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

2 2

[xwiki-devs] [Discussion] Some things that could be integrate in XE/XEM as a result of Wiki3.0
by Eduard Moraru 05 Aug '11

05 Aug '11

Hi devs, Based on my previous mail [1], I`ve isolated a small list of stand-alone elements that could be integrated into XE/XEM as a result of the work done on the Wiki3.0 research project: = XE = 1. Add 'Follow' button in GroupSheet's livetable - already done [3][4], needs a final review 1.1 Add 'About' and 'tags' columns in the GroupSheet's livetable. 2. Group Manager/Inviter (invite users to a group) - needs refactoring in order to extract it as an individual feature. = XEM= 3. Wiki descriptor editing from subwiki administration section - needs a bit of refactoring to make wiki descriptor editing and then reuse it for workspace descriptor editing. 4. Main wiki link in the top menu, under the 'Wiki' section to be able to go to the main wiki. I`d like to have your opinion on whether they are desired features to be integrated into XE/XEM. Note: Don`t forget to check out the demo instance [5] I`ve set up at http://wiki30-demo.xwiki.com to get a better view over the work done and, maybe suggest other things that could be reused. Thanks, Eduard ----------------- References: [1] http://xwiki.markmail.org/thread/3cbms22ctbqi4yqp [2] https://wiki30.xwikisas.com/ [3] https://github.com/xwiki/xwiki-platform/pull/14 [4] http://jira.xwiki.org/jira/browse/XWIKI-6770 [5] http://xwiki.markmail.org/thread/xngjqbq6e76owd37

2 2

[xwiki-devs] [Discussion] Defining Sheets
by Marius Dumitru Florea 04 Aug '11

04 Aug '11

Hi devs, A prerequisite for Application Within Minutes [1] is to be able to specify the sheet that will be used to display a document without touching the content of that document [2]. This can be done in multiple ways, depending on how we define the notion of a sheet. (1) Class sheets vs. document sheets A class sheet displays an object of a particular type and is specified in the definition of that type. This means that when you create or edit a class, i.e. a type of object, you can specify which sheet should be used to display the instances of that class. Pro: Documents don't have to specify a sheet. Con: We have to determine which sheet to use in case there are multiple objects attached to a document. A document sheet displays a document of a particular type and is specified at document level because the document type, unlike the xclass, does not exist actually. The document type is inferred from the type of objects the document has, or from its content, or, why not, from the type of attachments it has. Pro: Doesn't have the class sheet con. Con: Each document has to specify which sheet to use. Class sheets are enough for Application Within Minutes because the wizard will create a single class (with a sheet) and so the application items will have only one object that specifies a sheet. (2) Separate sheets per action? The current practice is to define a single (class) sheet which either checks for the current action in its code or uses doc.display method whose output is action specific. How often did you had the need to write separate sheets per action (e.g. create, view, edit, search, changes)? (3) Which actions require a sheet? If we're talking about class sheets then the list of actions that target an object and which require a sheet is limited. Currently we have "view" and "edit", but Ludovic proposed also "create", "search" and "changes". If we're talking about document sheets then we can have custom actions and so we need an extensible mechanism to map actions to sheets. (4) Sheet parameters? If we're talking about class sheets then they only need to specify how an object is displayed. Document sheets on the other hand may need to control elements like: * which tabs (comments, annotations, attachments, etc.), if any, are displayed * show title field in edit mode * the side panels * the form buttons WDYT? Thanks, Marius [1] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes [2] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…

7 14

Re: [xwiki-devs] Need help on creating virtual xwiki using API
by Eduard Moraru 04 Aug '11

04 Aug '11

Hi Karamjit, WikiManager plugin requires admin rights for handling subwikis. See http://jira.xwiki.org/jira/browse/XEM-113 for details and a workaround. Thanks, Eduard On Jul 31, 2011 5:08 PM, "Karamjit Singh" <karamjitmult(a)gmail.com> wrote: > > Yes. I have installed it already. I am getting bellow error message > " you donot have create wiki rights" > > Looks like a permission issue. Any idea how to set user in wikicontext? > On Jul 31, 2011 7:23 PM, "Eduard Moraru" <enygma2002(a)gmail.com> wrote: > > Hi Karamjit, > > > > On Sun, Jul 31, 2011 at 2:13 PM, Karamjit Singh <karamjitmult(a)gmail.com > >wrote: > > > >> Hi Team, > >> > >> I am not able to create virtual xwiki through the XwikiManagerPluginAPI. > I > >> have developed just sample restful web service. Below is the code which I > >> am > >> using to create virtual xwiki :- > >> > >> @Component("org.sisgma.xwiki.rest.HelloWorldResource") > >> @Path("/hello/") > >> public class HelloWorldResource extends XWikiResource { > >> public HelloWorldResource(){ > >> } > >> @GET > >> public String get(@DefaultValue("world") String myresourcename) throws > >> XWikiException, QueryException { > >> XWikiContext ctx = Utils.getXWikiContext(componentManager); > >> try { > >> WikiManagerPluginApi aoi = > >> > >> > (WikiManagerPluginApi)ctx.getWiki().getPluginApi(WikiManagerPlugin.PLUGIN_NAME, > >> ctx); > >> ctx.setDoc(new XWikiDocument(new DocumentReference("jaspreet", "space", > >> "page"))); > >> System.out.println("_____________********* deleting xwiki"); > >> aoi.deleteWiki("neenu", true); > >> aoi.deleteWiki("neenu1", true); > >> aoi.deleteWiki("karam", true); > >> System.out.println("_____________********* deleted xwikies"); > >> System.out.println("_____________********* Creating new xwiki"); > >> aoi.createNewWiki("jaspreet", "templatexe", > null,aoi.createWikiDocument(), > >> true); > >> > > > > Did you install the default template "templatexe"? > > > > > >> } catch (XWikiException e) { > >> e.printStackTrace(); > >> } > >> System.out.println("_____________********* " +ctx); > >> System.out.println("_____________"+ctx); > >> return "Hello " + myresourcename; > >> } > >> } > >> > >> Above code is not working. Virtual xwiki is not being created using the > >> API. > >> > > > > You should share the stack trace of the exception that is thrown. > > > > Thanks, > > Eduard > > > > > >> It is very urgent. Please help. > >> > >> Thanks > >> Karamjit. > >> _______________________________________________ > >> 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 > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

2 6

[xwiki-devs] [VOTE] Create twitter account for xwiki.org and use it to tweet releases
by Vincent Massol 03 Aug '11

03 Aug '11

Hi devs, I'd like to propose to create a twitter account for xwiki.org. The idea at first is to use it to announce new releases as part of the release process. More specifically to tweet a link to the blog post we write on xwiki.org at each release. Here's my +1 (I'll do it if we agree) Thanks -Vincent

10 9

Re: [xwiki-devs] [xwiki-platform] XWIKI-6808: Allow named queries to run with different storage engines. (cc100f8)
by Caleb James DeLisle 31 Jul '11

31 Jul '11

I see you have left comments here and in jira and neither of them seem to be there anymore. My reason for placing it in oldcore is the same as my reason for not using ConfigurationSource. The main store is chosen from a key in the xwiki.cfg file, if there's a ConfigurationSource for xwiki.cfg then I would like to know about it. I could have proposed moving the main store key to xwiki.properties but I made a guess that a proposal like that wouldn't fly. If a user ever does switch to a different store, telling him that he needs to change two configuration keys in two different files so that developers don't go in debt would not make sense to him. Caleb On 07/31/2011 02:45 AM, vmassol wrote: > I don't like the way you've fixed it too much (you've introduced some hacks) since using Initializable is the standard way of initializing components. The problem here can be fixed easily by not using the XWikiContext which in any case shouldn't be used. Instead configuration should come from a Configuration Source. > > Also you seem to be injecting the query executor but in init() you're looking it up again. > > Could you explain the need for this class and why it's located in the oldcore rather than being in the query manager's module? > > Thanks! >

2 1

[xwiki-devs] Recent build failures on agents
by Vincent Massol 31 Jul '11

31 Jul '11

Just fyi we received several emails about build failing for rendering. There were 2 issues: 1) the jenkins agent jar on the machines was not in sync with the jenkins version 2) Sergiu made a mistake during the release. He changed the java version to 1.5 (was 1.6). This makes the build fail since we require 1.6.... I personally don't like that we're doing releases from the agent machines, especially using the same user.... We should improve this. Thanks -Vincent

1 0

[xwiki-devs] Need help on creating virtual xwiki using API
by Karamjit Singh 31 Jul '11

31 Jul '11

Hi Team, I am not able to create virtual xwiki through the XwikiManagerPluginAPI. I have developed just sample restful web service. Below is the code which I am using to create virtual xwiki :- @Component("org.sisgma.xwiki.rest.HelloWorldResource") @Path("/hello/") public class HelloWorldResource extends XWikiResource { public HelloWorldResource(){ } @GET public String get(@DefaultValue("world") String myresourcename) throws XWikiException, QueryException { XWikiContext ctx = Utils.getXWikiContext(componentManager); try { WikiManagerPluginApi aoi = (WikiManagerPluginApi)ctx.getWiki().getPluginApi(WikiManagerPlugin.PLUGIN_NAME, ctx); ctx.setDoc(new XWikiDocument(new DocumentReference("jaspreet", "space", "page"))); System.out.println("_____________********* deleting xwiki"); aoi.deleteWiki("neenu", true); aoi.deleteWiki("neenu1", true); aoi.deleteWiki("karam", true); System.out.println("_____________********* deleted xwikies"); System.out.println("_____________********* Creating new xwiki"); aoi.createNewWiki("jaspreet", "templatexe", null,aoi.createWikiDocument(), true); } catch (XWikiException e) { e.printStackTrace(); } System.out.println("_____________********* " +ctx); System.out.println("_____________"+ctx); return "Hello " + myresourcename; } } Above code is not working. Virtual xwiki is not being created using the API. It is very urgent. Please help. Thanks Karamjit.

2 2