Hi All,
Is it possible to search(or get) a page in xwiki by its title through
RESTfulAPI?
I read in the forum that through RESTfulAPI we can only retrieve every page
in a space and check whether page with given title exists.
Or is it not the case?
Any help would be really appreciated.
Thanks,
Manish
--
View this message in context: http://xwiki.475771.n2.nabble.com/Searching-page-by-title-in-space-through-…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Salute!
Let me present you one of the largest worldwide enterprises where I work as a manager of HR department.
Our company is dealing with a great number of different fields, such as:
\ real estate
\ logistics
\ supporting in opening of banking accounts
\ etc.
And our company currently has vacant positions of regional managers in Europe:
- payment 2300 � +bonus
- max 3-4 business hours a day
- flexible working schedule
If you�re interested, please provide us your contact information in order we could contact you for further communication. Jordan(a)europ-joblist.com
Attention! We are recruiting only those who have a right to work in Europe!
We will be very happy to have you join our professional team.
Hello,
My question is about personal data management in XWiki.
How and where can I store personal data?
For example a user could have a different skin from the other users when
he logs in, or different documents (with personal content).
I'd like to know how to do it.
Thanks,
Marie
Hi guys (especially Ludovic and Thibaut),
I read [1] and [2] and I have a few questions. I would like to know very
clear what UI/UX platform changes are you proposing independent of the
Application Within Minutes.
(A) Page creation
1. Unique page name
Currently if you specify the name of an existing page in the default
create page form you get an error message saying that the specified page
already exists. Do you propose any change to this? Should we instead
create a page with a similar name based on a specified strategy (e.g.
MyPage1, MyPage2, with a simple counter strategy).
2. Skip page name
Do you propose to remove the page name field from the default create
page form (triggered from the Add > Page menu) and to automatically
generate it from the title (using the default naming strategy)?
3. Implicit location
Do you propose to remove the wiki/space fields from the default create
page form and instead always create the page in the current wiki/space?
i.e. Add > Page menu will add the page to the current wiki/space.
4. Implicit template
Currently template providers can be limited to a list of spaces. Do you
propose to automatically use a template provider if it is the only one
defined for the current/selected space?
5. Create sheet/template
Are you proposing to have a (slightly) different form even for plain
wiki pages? e.g. replace the "Save & Continue" and "Save" buttons with a
"Create" button. What other differences do you propose?
-----
I talked with Caty about this and she is against 3. and 4. She would
improve the current create page form by:
* displaying all the templates independent of the current space
(currently we display only the templates that can be applied to the
current space although we can create the page in a different space)
* when a template is selected, limit the list of spaces from the space
selector so that the user can choose only a space where the selected
template can be applied.
(B) Display Resolution
(1) Remove the "inline" editing mechanism
What do you propose to do with the "Edit > Inline form" menu seen by the
advanced users? Should we keep it and just replace the URL? What about
simple users, will they be noticing any difference (since we already
have just one Edit button that points to the proper edit mode)?
(2) Sheet parameters
Do you mean velocity variables defined in the sheet code? This will work
only if the variables are used after the sheet code is evaluated.
(3) Display Resolution Rules
I could find fields for specifying display sheets (defaultViewSheet and
defaultEditSheet) only in BaseClass (old core). XWikiDocument doesn't
have any. This makes sense because sheets are in fact *class* sheets.
That is, you write a sheet for a specific class, you don't write it for
a specific document. Have I understood correctly that you want to be
able to create a sheet for a document (not a class)? This could be
useful for documents that have multiple objects and you need a sheet
that displays data from all the objects (using the class sheet of one of
the object types is not enough).
Thanks,
Marius
[1]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesPageCrea…
[2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
Hi, According to the discussion with Marius, I list the work plan for this
week(6.27-7.3).
Implement the skeleton of the auto-suggestion functions include following
things:
(1). Implement the function that logs a message in the firebug console
whenever the caret is after [[ (but just that, nothing more!)
(2). Implement the function that requests the list of wiki pages matching
some prefix user input. BUT, don't actually query the database, instead
simply return a dummy list from the server.
(3). Implement the function that displays the list of wiki pages where the
caret is, but using just a plain HTML list inside a DIV. *Nothing fancy*. No
CSS!
All these three things covers all the proccesses of the auto-suggestion
functions, it will give an overview of the whole projects, and the rest of
work will refine the skeleton gradually later.
--
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,
The proposal is to make all click methods be named click*() in UI functional tests.
For example in ViewPage, instead of:
public LoginPage login()
{
this.loginLink.click();
return new LoginPage();
}
We would have:
public LoginPage clickLogin()
{
this.loginLink.click();
return new LoginPage();
}
Right now we have some methods starting with click and other not following this pattern, the idea is to homogeneize it.
WDYT?
Thanks
-Vincent
Hi, These days with the help of Marius, I seperate my codes into
sub-modules, and commit them with their test modules one by one
In last week I have committed two modules:
1. suggestion box for link (
http://farm6.static.flickr.com/5268/5599744930_ff65ddfdc3_z.jpg)
2. suggestion box for image (
http://farm6.static.flickr.com/5063/5600563446_5f15f500d1_z.jpg)
I have also written a readme document in the same dir of the two modules, to
guide developers to run and test the modules seperately.
--
Best wishes,
许凌志(Jame Xu)
MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University
Department of Computer Science and Technology, Xi’an Jiaotong University
Dear All,
I'm working on the Calendar Application and I would like a few opinions on
how to structure it.
Details about the application can be found here:
http://incubator.myxwiki.org/xwiki/bin/view/Drafts/CalendarApplication and
my main problem is choosing between the presented alternatives.
A few important pieces of information about the application:
- every event is a document with an object of EventClass attached
- every calendar is a document with an object of CalendarClass attached
- whenever a calendar is added, a space is also created. This space will
store the calendar doc and the events associated with the calendar
The functionality can be found on incubator.
The alternatives are:
*Calendar aggregator*
The WebHome of the application is an aggregated calendar which displays the
events from all the calendars of a user.
The user creates several calendars (e.g. Personal, Work) which can be
visualized both individually and together, on the main page of the
application.
This is very similar to Google Calendar, following the same approach. The
main advantage of this is the ease of interaction between users' calendars
(e.g. sharing a calendar with another user means displaying the specific
calendar among his own calendars, inside the WebHome).
*Individual calendars with categories*
The users creates calendars which are individual entities and each event is
assigned a category when added.
When the user is invited to other events he can choose to view those events
in one or more of his calendars while when another user shares a calendar
with him he can only view that calendar, on a separate page.
As far as I see it, the first choice means easier interaction between users
but considering the number of events that must be selected every time,
performance might not be that good.
Please let me know which of the two you consider to be better or, if you
have another solution, which might that be.
Thanks,
Vlad
Hi everyone. I'm looking for a programmatic way to generate XWiki pages
that include objects.
I have looked at generating XAR files for import, but am wondering if
there are other ways to generate pages from code with no user
interaction. Any pointers would be appreciated.
-Mark
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The XWiki development team is proud to announce the release of XWiki Enterprise 3.1 Final.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This is the first ever release to be tested in a staging repository and is probably the most well tested release to date.
You can review the changes made since 3.0 by going to:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…
Thanks
- -The XWiki development team
If you would like to download the new release now, you can using these links:
- ---- XWiki Enterprise for Servers ----
xwiki-enterprise-web-3.1.war
SHA1: 5321b065247027cffb2b139bbe9db876e079f4ca
http://forge.ow2.org/project/download.php?group_id=170&file_id=16846
xwiki-enterprise-wiki-3.1.xar
SHA1: d80a7611d19dc28717a4538efe49cfd4858f94ec
http://forge.ow2.org/project/download.php?group_id=170&file_id=16847
- ---- XWiki Enterprise Standalone ----
xwiki-enterprise-installer-windows-3.1.exe
SHA1: c2ba74cfae30e272566f4e6ce7435d14ae9df2e3
http://forge.ow2.org/project/download.php?group_id=170&file_id=16845
xwiki-enterprise-jetty-hsqldb-3.1.zip
SHA1: 82a80420f48b7d0614822137498251e7fc01e889
http://forge.ow2.org/project/download.php?group_id=170&file_id=16844
xwiki-enterprise-installer-generic-3.1-standard.jar
SHA1: 7a038ce14be2b75bdaecb816bcf699f221908d9b
http://forge.ow2.org/project/download.php?group_id=170&file_id=16843
- ---- XWiki Manager for Servers ----
xwiki-manager-web-3.1.war
SHA1: abdf4e758246cabf4a1af79337e8170bfc582b1e
http://forge.ow2.org/project/download.php?group_id=170&file_id=16848
xwiki-manager-wiki-administrator-3.1.xar
SHA1: 9e2c9a2b02f87060c657c70bf15e4721df7e4f6c
http://forge.ow2.org/project/download.php?group_id=170&file_id=16850
- ---- XWiki Manager Standalone ----
xwiki-manager-jetty-mysql-3.1.zip
SHA1: f6277fd61c412642300427440798fd27938651cf
http://forge.ow2.org/project/download.php?group_id=170&file_id=16851
- ---- XWiki Manager Extension for XWiki Enterprise Installations ----
xwiki-manager-application-xem-3.1.xar
SHA1: f22abfd671527f6ef293d3763b8e688e2f0c100d
http://forge.ow2.org/project/download.php?group_id=170&file_id=16849
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAEBAgAGBQJOAL4sAAoJECYAmptlsgnWNk8P/jDYcGMDioM+DCzaN69Ljo5F
De3EQQL0c++OjkC+R/s3kzxoHFk9g2Sa8bWjjDYIqiORiV1eIbJ1RnV5Tc31G5xA
Q5MastEQ9onzQalXnZDJhrwwSw2CYMk9sia3bWBDPi55zuSKJvSar7Zgg85xE953
0a+Xmp2bCECc8QI8taeqyOnpAmvHR3NG6sKFc6biVRTBcU93XhUVZVPmjZixvupR
fxo3gVmyX4G9RbNJFKxHZkHyEHcRdW1+7vdR9Dj3qZBTGBs+2jAHR3Xl6LEjyAb6
+NrZsmHf590jnrvrrl4t0Ld5kaG4ykHICShOZRIrZ8VylBTylHl+Zgx38imQ818J
/YVEdjCGh6iqOHF1BQM4aeiAFw/Ja3EiqjpUkrqtMH5pjfbMU3qNNxKAtP4WKdac
xDZaUZddMcKGauA7Qc27YkQkl7Nkvb4A3ikNld/PZs2QfDPEJsytrz6VqAgnLfwO
Q4H6rvltysCbv/v05V2/jgUrNtXsnUa2NSOXjYVrsdiQh71qTph9I+nNbjk35gs/
dD8TaFxejMmu68qUcOR2aFIRncO2QKlbff8dN1UfkXJ7dd/HVS/1/1YtBQWiIqjk
TWRS3KVgf4tgo1yHGyedBIkSCo3+iHffUyMPkmZoxJ9fnzvVWRi7eOQWOUwCOqWd
Lg7wLAAwbJWY1rdpiXAT
=78pa
-----END PGP SIGNATURE-----
Hi, These days I am trying to build the framework for auto-completion
features for wiki editors. And part of codes I have committed to github.
Hope you can reveiew the code for me. I haven't made pull request yet,
because the codes are not complete and full tested, I will update them
almost everyday. So I don't know if pull the request is neccessary.
--
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,
For now I've implemented almost all the REST GET methods in
xwiki-android-client. Translations and some of the Objects method will be
implemented as soon as possible.
I modified jaxb model classes to work with GSON which is a json deserializer
works in Android.
xwiki-android-rest is downgraded from android SDK version 2.2 to 2.1.1 for
achieving more compatibility with the devices.
Currently I'm having an issue in all the REST requests which has date/time
because REST replies date/time as a java.util.GregorianCalendar object with
using sun.util.calendar.ZoneInfo as the timezone. Android doesn't
have sun.util.calendar library and because of that json objects cannot be
deserialize using GSON.
Therefore I manually deserialized ZoneInfo content. So now TimeZone data can
be added to any other common library which can be used with xwiki as well as
Android. Please suggest me such library.
Android Xwiki navigator
Thomas suggested to make a developer widget which serves as a
xwiki-navigator. (
http://developer.android.com/guide/topics/ui/custom-components.html)
But these developer widget are only used for designing custom user
interfaces and functionality should be added as same as normal android
application. So there is no significant advantage of building developer
widget. Anyway I'll do it.
Best Regards,
Chamika Weerasinghe
Hi devs,
I forgot to propose dates in the Roadmap mail for XE 3.2 so here's a proposal:
3.2M1: 18 July 2011
3.2M2: 15 August 2011
3.2M3: 12 Sep 2011
3.2RC1: 26 Sep 2011
3.2 Final: 10 Oct 2011
Rationale:
- 4 week for milestone releases
- 2 weeks for RC and Final
- 1 more milestone than usual since it's holiday time and most committers will be off at least 2 to 4 weeks during the summer
Here's my +1
Thanks
-Vincent
Hi there!
We are trying to use XWiki 3.0 enterprise, trying to create via XML-RPC
thousands of users, groups and membership programmatically so we can
keep updated AD, Liferay, other sources of users, other apps, all with
CAS integration, etc.
As there is still no confluence 2.0 API compatibility but we need to
create users & groups in XWiki from an external software, we have been
collecting pieces of code from messages and FAQs about how to implement
it.
We try to create users, their pages, and add them to the XWikiAllGroup
with :
Page page = new Page();
page.setSpace("XWiki");
page.setTitle("username01");
page.setId("XWiki.username01");
page.setContent("{{include
document=\"XWiki.XWikiUserSheet\"/}}");
rpc.storePage(page);
XWikiObject xobj = new XWikiObject();
xobj.setClassName("XWiki.XWikiUsers");
xobj.setPageId("XWiki.username01");
xobj.setProperty("first_name", "name");
xobj.setProperty("last_name", "last name");
xobj.setProperty("email",
"email(a)email.com");
xobj.setProperty("password","##########");
rpc.storeObject(xobj);
XWikiObject xobjgrp = new XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("XWiki.XWikiAllGroup");
xobjgrp.setProperty("member","XWiki.username01");
rpc.storeObject(xobjgrp);
(Suppose we run that with username01 to username99)
Although first time we run this, the page gets created, the user gets
created but the properties not! :-o
If we run again the import, then every user gets their properties. :-?
Then, only the LAST user created gets correctly added to
XWiki.XWikiAllGroup. If we stop/debug the program between each user
creation process, always the last one appears at XWiki.XWikiAllGroup
when checking via UI. So they are all there for a moment, until they are
replaced by the last one. Like if the rpc.storeObject(xobjgrp) deleted
previously any other user in that XWiki.XWikiAllGroup page.
Then we try to create groups using this:
// create group 01
Page page = new Page();
page.setSpace("XWiki");
page.setTitle("group01");
page.setContent("{{include document='XWiki.XWikiGroupSheet' /}}");
rpc.storePage(page);
// create group 02
Page page = new Page();
page.setSpace("XWiki");
page.setTitle("group02");
page.setContent("{{include document='XWiki.XWikiGroupSheet' /}}");
rpc.storePage(page);
...
Those "Groups" get created as Pages with XWikiGroupSheet app that allows
us to see/edit the users via UI, but we need to add them via XML-RPC.
ALSO, they are Pages, but they are NOT EXACTLY the same as if they where
created via the Admin UI, where when you create a "Group" it shows
slightly differently:
Autocreated via XML-RPC:
Versus when a group is created via Admin UI, it shows up differently,
just like this:
SO, we suppose the way we create a Group via XML-RPC (just a Page with a
special Sheet) is NOT ENOUGH.
And finally we try to add existing users to newly created groups with
code like this:
// user 01 to group 01
XWikiObject xobjgrp = new
XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("group01");
xobjgrp.setProperty("member","XWiki.username01");
rpc.storeObject(xobjgrp);
// user 01 to group 02
XWikiObject xobjgrp = new
XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("group02");
xobjgrp.setProperty("member","XWiki.username01");
rpc.storeObject(xobjgrp);
// user 02 to group 01
XWikiObject xobjgrp = new
XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("group01");
xobjgrp.setProperty("member","XWiki.username02");
rpc.storeObject(xobjgrp);
// user 03 to group 01
XWikiObject xobjgrp = new
XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("group01");
xobjgrp.setProperty("member","XWiki.username02");
rpc.storeObject(xobjgrp);
...
If now we check the group via UI, we can find Pages named XWiki.group01
, XWiki.group02, and with only one user each (although in the code up
there username 01, 02 and 03 should be members of group01 !!! only THE
LAST ONE (username03) remains.
Also we tried to add also some users to the default (pre-created)
XWiki.XWikiAdminGroup so they can act as administrators:
XWikiObject xobjgrp = new
XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("XWiki.XWikiAdminGroup");
xobjgrp.setProperty("member","XWiki.username01");
rpc.storeObject(xobjgrp);
XWikiObject xobjgrp = new
XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("XWiki.XWikiAdminGroup");
xobjgrp.setProperty("member","XWiki.username02");
rpc.storeObject(xobjgrp);
As before only XWiki.username02 stays as member of
XWiki.XWikiAdminGroup.
We tried this with a fresh install of XWikiEnt3.0+Jetty+HSQLDB, then in
Tomcat+MySQL, same problem in all of them.
So, are we doing something wrong? Maybe something must be done with
every user or group before you can add membership via XML-RPC?
Sorry for the long post and thanks in advance!
Bernardo Riveira
Hi there!
We are trying to use XWiki 3.0 enterprise, trying to create via
XML-RPC thousands of users, groups and membership programmatically so
we can keep updated AD, Liferay, other sources of users, other apps,
all with CAS integration, etc.
As there is still no confluence 2.0 API compatibility but we need to
create users & groups in XWiki from an external software, we have been
collecting pieces of code from messages and FAQs about how to
implement it.
We try to create users, their pages, and add them to the XWikiAllGroup
with :
Page page = new Page();
page.setSpace("XWiki");
page.setTitle("username01");
page.setId("XWiki.username01");
page.setContent("{{include
document=\"XWiki.XWikiUserSheet\"/}}");
rpc.storePage(page);
XWikiObject xobj = new XWikiObject();
xobj.setClassName("XWiki.XWikiUsers");
xobj.setPageId("XWiki.username01");
xobj.setProperty("first_name", "name");
xobj.setProperty("last_name", "last
name");
xobj.setProperty("email",
"email(a)email.com");
xobj.setProperty("password","##########");
rpc.storeObject(xobj);
XWikiObject xobjgrp = new XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("XWiki.XWikiAllGroup");
xobjgrp.setProperty("member","XWiki.username01");
rpc.storeObject(xobjgrp);
(Suppose we run that with username01 to username99)
Although first time we run this, the page gets created, the user gets
created but the properties not! :-o
If we run again the import, then every user gets their properties. :-?
Then, only the LAST user created gets correctly added to
XWiki.XWikiAllGroup. If we stop/debug the program between each user
creation process, always the last one appears at XWiki.XWikiAllGroup
when checking via UI. So they are all there for a moment, until they
are replaced by the last one. Like if the rpc.storeObject(xobjgrp)
deleted previously any other user in that XWiki.XWikiAllGroup page.
Then we try to create groups using this:
// create group 01
Page page = new Page();
page.setSpace("XWiki");
page.setTitle("group01");
page.setContent("{{include document='XWiki.XWikiGroupSheet' /}}");
rpc.storePage(page);
// create group 02
Page page = new Page();
page.setSpace("XWiki");
page.setTitle("group02");
page.setContent("{{include document='XWiki.XWikiGroupSheet' /}}");
rpc.storePage(page);
...
Those "Groups" get created as Pages with XWikiGroupSheet app that
allows us to see/edit the users via UI, but we need to add them via
XML-RPC.
ALSO, they are Pages, but they are NOT EXACTLY the same as if they
where created via the Admin UI, where when you create a "Group" it
shows slightly differently:
Autocreated via XML-RPC:
[cid:image001.png@01CC2C45.659F3540]
Versus when a group is created via Admin UI, it shows up differently,
just like this:
[cid:image002.png@01CC2C45.659F3540]
SO, we suppose the way we create a Group via XML-RPC (just a Page with
a special Sheet) is NOT ENOUGH.
And finally we try to add existing users to newly created groups with
code like this:
// user 01 to group 01
XWikiObject xobjgrp =
new XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("group01");
xobjgrp.setProperty("member","XWiki.username01");
rpc.storeObject(xobjgrp);
// user 01 to group 02
XWikiObject xobjgrp =
new XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("group02");
xobjgrp.setProperty("member","XWiki.username01");
rpc.storeObject(xobjgrp);
// user 02 to group 01
XWikiObject xobjgrp =
new XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("group01");
xobjgrp.setProperty("member","XWiki.username02");
rpc.storeObject(xobjgrp);
// user 03 to group 01
XWikiObject xobjgrp =
new XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("group01");
xobjgrp.setProperty("member","XWiki.username02");
rpc.storeObject(xobjgrp);
...
If now we check the group via UI, we can find Pages named
XWiki.group01 , XWiki.group02, and with only one user each (although
in the code up there username 01, 02 and 03 should be members of
group01 !!! only THE LAST ONE (username03) remains.
Also we tried to add also some users to the default (pre-created)
XWiki.XWikiAdminGroup so they can act as administrators:
XWikiObject xobjgrp =
new XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("XWiki.XWikiAdminGroup");
xobjgrp.setProperty("member","XWiki.username01");
rpc.storeObject(xobjgrp);
XWikiObject xobjgrp =
new XWikiObject();
xobjgrp.setClassName("XWiki.XWikiGroups");
xobjgrp.setPageId("XWiki.XWikiAdminGroup");
xobjgrp.setProperty("member","XWiki.username02");
rpc.storeObject(xobjgrp);
As before only XWiki.username02 stays as member of
XWiki.XWikiAdminGroup.
We tried this with a fresh install of XWikiEnt3.0+Jetty+HSQLDB, then
in Tomcat+MySQL, same problem in all of them.
So, are we doing something wrong? Maybe something must be done with
every user or group before you can add membership via XML-RPC?
Sorry for the long post and thanks in advance!
Bernardo Riveira
*****
Este mensaje se dirige exclusivamente a su destinatario. Puede contener información privilegiada, confidencial o legalmente protegida.
Si ha recibido este mensaje por error le rogamos que lo borre inmediatamente, así como todas sus copias, y lo comunique al remitente.
En virtud de la legislación vigente está prohibida la utilización, divulgación copia o impresión sin autorización.
No existe renuncia a la confidencialidad o privilegio por causa de una transmisión errónea.
*****
Hi dev,
Currently each time you modify XWikiPreference all the plugin are
reloaded and reinitialized. This is very bad so I would like to remove
this. Also this is done only when not in vistual mode (what the...).
If either a plugin cache something coming from XWikiPreference it
should register to event itself and update its cache when needed.
I don't know any plugin which actually count on this "feature".
My proposal is to simply remove this code which is useless and does
not even work in virtual mode anyway.
WDYT ?
Here is my +1
--
Thomas Mortagne
Hi,
For now I added Wiki and Space and the Search access in xwiki-android-rest
via handling JSON objects.
I commited new files to repo.
When I implementing access to Page resources I found that Xwiki REST sends
different contents in XML and JSON
For example
XML content
http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Blog/pages/BlogIntroduc…
is different from
JSON content
http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Blog/pages/BlogIntroduc…
Because of this difference I decided to deserialize XML instead of JSON. (I
must modify all the class files for this).
XWiki RESTful API doc (
http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI) describes
XML -> Java conversion by using "org.apache.commons.httpclient".
But this library seems to be larger in size. As Thomas said size does matter
in Android. Therefore I decided to use "org.apache.http" which built in
Android.
But I got following error
06-12 20:02:55.070: WARN/dalvikvm(650): VFY: unable to resolve static method
1169: Ljavax/xml/bind/JAXBContext;.newInstance
(Ljava/lang/String;)Ljavax/xml/bind/JAXBContext;
Can anybody suggest me what causes this error?
Best Regards,
Chamika Weerasinghe
Hi committers,
We're having a hard time stabilizing our build (especially the functional test part, see my previous mail entitled "[VOTE] Important: Strategy to fix failing tests and stability"). Now I believe that it's going to be hard to enforce it and thus I'd like to propose a variation:
* The Build Manager has the *responsibility* to get the build fixed ASAP whenever it's failing. His priority #1 during the week becomes monitoring the Build
* By "Build" we mean the CI Build on ci.xwiki.org and by "failing" we mean anything that makes the build fail: tests, compilation, clirr, etc.
* Every week we have a different Build Manager chosen amongst the Committers
* In order to fix build issues the Build Manager has several possibilities:
- find out who caused the build to break and ask that person to fix it. That person cannot refuse that and must consider it his/her priority to fix it (or rollback the change that caused the build to fail)
- rollback the issue that caused the build to fail
- fix it himself/herself
- find someone knowledgable in the failing domain and get him/her to fix the build.
* At the end of the Week the Build Manager hands over his duty to the next Build Manager by contacting him/her.
* We create a Build Manager Roster page on dev.xwiki.org to log past Build Managers (and possibly future ones if some have expressed the wish to be the Build Manager for a specific week).
* All committers must perform this duty and take turns
Since I've started doing this this week, I propose to take this role for the current week. I'm also proposing to log Caleb has having been the Build Manager for the past week since he's done a lot to stabilize the build.
If the vote is passed I'll log this on the Committership page as a Committer duty (I'll also cross reference it from the Build page).
Here's my +1
Thanks
-Vincent
I am working on this project all the days following your instructions we
discussed before. And the mainly work I have done are following :
(1). Set up the framework for auto-suggestion, including three parts:
a).The main object XWiki.editors.AutoSuggestion which is the entry for
trigger auto-suggestion functions
b).XWiki.editors.AutoSuggestion.Suggestor, which is only for wiki
editors, and the main function is give the right suggestions according to
user input in different context of triggers. The suggestor includes:
XWiki.editors.AutoSuggestion.LinkSuggestor,
XWiki.editors.AutoSuggestion.ImageSuggestor and
XWiki.editors.AutoSuggestion.MacroSuggestor.
c).XWiki.editors.autoSuggestion.SuggestionList, whic is the used for
initializing the suggestion box, there are three kinds of SuggestionList:
XWiki.editors.autoSuggestion.LinkSuggestionList,
XWiki.editors.autoSuggestion.ImageSuggestionList,
XWiki.editors.autoSuggestion.MacroSuggestionList.
(2). I finished the XWiki.editors.autoSuggestion.SuggestionList and
XWiki.editors.autoSuggestion.LinkSuggestionList. include the related css, it
is more like a widget, can be instantiated alone, so that it can be used in
Wysiwyg editors
(3). Finish part of the main object : XWiki.editors.AutoSuggestion(only for
testing Link SuggestionList)
(4). Working on the XWiki.editors.AutoSuggestion.Suggestor and
XWiki.editors.AutoSuggestion.LinkSuggestor for wiki editors.
I don't commit the code because it is only part of them, and some of them
can not run properly right now, In my plan, I will commit tonight maybe the
in the afternoon in your time zoon.
Sorry for commit late, because start is hard, I will increase the commit
times, after the first commit, it will be helpful for mentors to review the
code
On Mon, Jun 13, 2011 at 6:03 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
> Hi James,
>
> Any progress on the GSoC project? Time is passing and I haven't seen any
> commit from you. Asking for feedback is very important as it gives you the
> guarantee that you're going in the right direction. For instance, I don't
> know what you're working on currently.
>
> Thanks,
> Marius
>
--
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,
I'm Pulasthi and currently working on the Scalable XWiki on NoSQL (Cassandra
) project with Caleb James DeLisle. i got involved with the project as a
GSOC applicant but the project was not selected for GSOC. i thought of
informing the devs about my progress. As the project needed to use the Todd
Nines Datanucleus Cassandra plugin which was not capable of querying non
indexed queries. As the first part of the project i was able to successfully
add a patch[1] to this and made some changes after getting feedback from
Caleb James.
[1] .Datanucleus Cassandra plugin with patch -
https://github.com/pulasthi/Datanucleus-Cassandra-Plugin
--
Pulasthi Supun
Undergraduate
Dpt of Computer Science & Engineering
University of Moratuwa
Since there has not been much change since The last release I think we can get largely back on track. I understand Monday is a holiday for a number of people so I would like to propose releasing on Tuesday.
That means we will need to start testing ASAP and I would like to know now if anybody knows of an issue which is a blocker for the 3.1 release.
Thanks
Caleb