Dear all,
I've committed a first implementation of the RESTful API as described on
http://dev.xwiki.org/xwiki/bin/view/Design/RestfulAPI
Not all the URIs are working but pages and translations are.
You can:
* GET /
* GET /spaces
* GET /spaces/{spaceId}/pages
* GET|PUT /spaces/{spaceId}/pages/{pageId}
* GET|PUT /spaces/{spaceId}/pages/{pageId}/translations/{translationId}
PUT will create/modify the corresponding page.
You can use curl to interoperate with the API. Some examples:
* curl -u Admin:admin -X PUT -d "Hello world" -H "Content-Type:
text/plain" http://localhost:8080/xwiki/rest/spaces/Main/pages/WebHome
Will set the content of Main.WebHome to "Hello world"
* curl -u Admin:admin -X PUT -d @text.txt -H "Content-Type: text/plain"
http://localhost:8080/xwiki/rest/spaces/Main/pages/WebHome
Will set the Main.WebHome content to whatever is writen in the text.txt
file.
* curl -u Admin:admin -X PUT -d @page.xml -H "Content-Type:
application/xml" http://localhost:8080/xwiki/rest/spaces/Main/pages/WebHome
Will set the Main.WebHome attributes to whatever is written in the
page.xml. The xml file must conform to the structure described in the
design page. This allows to change the content, the title and to
reparent the page.
* curl -u Admin:admin -X PUT -d @text.txt -H "Content-Type: text/plain"
http://localhost:8080/xwiki/rest/spaces/Not/pages/Existing
Will create the Not.Existing page and set its content to whatever is
writen in the text.txt file.
Currently the implementation is in the sandbox and is available for
public review
(http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-core-rest/). It uses
the XStream library (http://xstream.codehaus.org) for XML
serialization/deserialization of data types. Very handy.
Comments are welcome.
-Fabio
Hi,
I think it might be interesting to export a document's structure (the
XDOM) to the XML we generate for pages (?xpage=xml), in addition to
the unparsed content and the rendered content.
This would make it easy for external tools to process page structures
and extract required information. More importantly it's something easy
to do now.
WDYT? This is low priority but I thought it could be interesting.
Technically this means writing a DOMListener (which creates a w3c
Document from a XDOM).
Thanks
-Vincent
Hi Devs,
I'm upgrading office-importer code base to new architecture. For this I
suggest following methods to be added to the DocumentAccessBridge:
1. createNewDocument(String documentName, String content) //This method will
throw an exception if the document already exists.
2. setDocumentContent(String documentName, String newContent) //For updating
an existing document.
3. setDocumentSyntaxId(String documentName, String syntaxId) //For
presentation documents the syntax would be 1.0 and for others it would be
2.0
4. addAttachmentToDocument(String documentName, String AttachmentName, byte
[] attachmentData) //For making attachments
5. isDocumentEditable(String documentName) //This is following
isDocumentViewable() mthod. But we could also have a hasRight() mthod
instead.
I'm +1 for all. But please let me know if any of above methods are redundant
/ not required / has wrong signature.
Thanks.
- Asiri
Hi everyone
Currently the XWiki 2.0 parser does not support multilines headers,
meaning that it consider new line as end of header:
= Heading
1 =
give "<h1>Heading</h1><p>1 =</p>"
I propose to have the same things than paragraphs: need two
consecutive new lines (or the =* syntax of course) to be end of
header.
= Heading
1 =
= Heading
2 =
would give "<h1>Heading<br/>1</h1><h1>Heading</h1><p>2 =</p>"
Here is my +1
Thanks,
--
Thomas Mortagne
On Dec 29, 2008, at 10:49 AM, Ludovic Dubost wrote:
> Marius Dumitru Florea wrote:
>> ludovic (SVN) wrote:
>>
>>> Author: ludovic
>>> Date: 2008-12-29 10:10:55 +0100 (Mon, 29 Dec 2008)
>>> New Revision: 14946
>>>
>>> Modified:
>>> platform/web/trunk/standard/src/main/webapp/templates/
>>> editwysiwygnew.vm
>>> Log:
>>> XWIKI-3046 GWT Editor SyncPlugin: correct loading of initial
>>> content supporting images. Added a reset sync action
>>>
>>> Modified: platform/web/trunk/standard/src/main/webapp/templates/
>>> editwysiwygnew.vm
>>> ===================================================================
>>> --- platform/web/trunk/standard/src/main/webapp/templates/
>>> editwysiwygnew.vm 2008-12-29 09:10:38 UTC (rev 14945)
>>> +++ platform/web/trunk/standard/src/main/webapp/templates/
>>> editwysiwygnew.vm 2008-12-29 09:10:55 UTC (rev 14946)
>>> @@ -47,11 +47,16 @@
>>> hookId: 'content',
>>> #if($request.sync=="1")
>>> syncPage: '$doc.fullName',
>>> + plugins: 'separator text valign list indent undo format
>>> symbol link image table sync',
>>>
>>
>>
>>> + inputURL: "${request.contextPath}/
>>> com.xpn.xwiki.wysiwyg.Wysiwyg/empty.html",
>>>
>>
>>
> Well I need a read empty content, and the issue is that when
> parseTemplate returns empty this is not considered as ok and will
> generate an error. So I have to use a real static HTML. What I need is
> not the exact relative path but the server part name so that images
> display properly.
>
> This is currently working. This is good enough for now and specific to
> the sync method, since this is demo code. We can change it later.
Well this definitely needs comments since it's a hack and not an
obvious one.
Thanks
-Vincent
> Ludovic
>
>> Why do you need this empty.html? Did you try setting the wysiwyg
>> input
>> to an empty string?
>>
>> #set($ok = $wysiwygInput.put($wysiwygInputKey, "")) ?
>>
>> Plus, all the links and images will be relative to
>> ${request.contextPath}/com.xpn.xwiki.wysiwyg.Wysiwyg and this is
>> not good.
>>
>>
>>> + #if($request.reset=="1")
>>> + syncReset: 1,
>>> + #end
>>> #else
>>> inputURL: "${tdoc.getExternalURL("view",
>>> "xpage=wysiwyginput&key=$wysiwygInputKey")}",
>>> + plugins: 'separator text valign list indent undo format
>>> symbol link image table',
>>> #end
>>> syntax: "$doc.syntaxId",
>>> - plugins: 'separator text valign list indent undo format
>>> symbol link image table',
>>> toolbar: 'bold italic underline strikethrough | subscript
>>> superscript | unorderedlist orderedlist | outdent indent | undo
>>> redo | format | hr symbol | link unlink | image | inserttable
>>> deletetable | insertrowbefore insertrowafter deleterow |
>>> insertcolbefore insertcolafter deletecol',
>>> space: '${doc.space}',
>>> page: '${doc.name}',
Dear all,
I am starting a new thread because the old one started to be overloaded.
I have started to write some media types that could be used as the
representations returned by our RESTful API.
It's a first attempt but they already contain some ideas and the guiding
design principle I would like to follow.
You can find them on http://dev.xwiki.org/xwiki/bin/view/Design/RestfulAPI
Comments are welcome.
-Fabio