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
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
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 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
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…
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
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!
>
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
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.