Re: [xwiki-devs] questions about XWiki-5820

On Thu, May 19, 2011 at 7:53 AM, Jun Han <jun.han37(a)gmail.com> wrote: Well, I think this solution is not good because if we want to add more media types (e.g., PDF, etc.) we should introduce a lot of URIs. Instead we can leverage the current ones and use HTTP metadata to produce the right output. To do this we have 2 ways: 1) Either we define a MessageBodyWriter (http://jsr311.java.net/nonav/javadoc/javax/ws/rs/ext/MessageBodyWriter.html) that @Produces("text/html") for an org.xwiki.rest.model.jaxb.Page object that is returned by PageResource.getPage() (i.e., the method that is called when GET is called on the /wikis/{wikiName}/spaces/{spaceName}/pages/{pageName} URI) 2) Or we enhance the PageResource class by providing a new method, e.g., getPageHTML that @Produces("text/html") and returns a String which is the actual rendered content. @Produces is the annotation that enables content negotiation. If a client requests a specific media type, the @Produces is used by the framework to locate the entity that should provide the response. The first option is better wrt modularity but it has a problem. The org.xwiki.rest.model.jaxb.Page doesn't have any link to the original XWiki Document from where it has been built, so we cannot directly call getRenderedContent. A quick solution would be to re-get the associated XWiki Document based on the information present in the org.xwiki.rest.model.jaxb.Page object and call getRenderedContent(). A bit ugly because this makes the work done in the getPage() method useless. The second option is straightforward, works fine and doesn't have the drawbacks of the first but introduces a second way for adding media format support. I mean this is perfectly legal in JAX-RS, it's just that from an architectural point of view, it is nice to have media type support using body writers because they are XWiki components and they can be injected in the system without touching existing code (giving more flexibility and better extensibility) So how do we proceed? To do 1) I think we should refactor a the whole system in order to make original XWiki entities to be accessible from JAXB objects. Since we are using a JAXB compiler to automatically generate these classes from an XSD schema, I am not sure that we can tell the compiler to "add an Object entity field to the generated classes" (have to check if). If this is possible then we're done, otherwise we might need to stop using the compiler and write explicitly the classes using JAXB annotations for serializing only the relevant fields. 2) as I said is straightforward. Since my idea was to give you some insights about how the REST API works, I think you can implement 2) because 1) is too much (though, if you feel comfortable you might try :)). This mail and your implementation should provide you enough background to understand how things work under the hood in case we'll need to patch some things server side while working on XEclipse. So try to go for 2). You can also have a look at the JAX-RS specification that details all the concepts I've mentioned before and that we use in the RESTful API backend. Thanks, Fabio _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs