Re: Resources and Representations
On #1, I don't know much about Atom but if it's an XML type feed, I'd extend XmlRepresentation, SaxRepresentation, or DomRepresentation, or at the very least OutputRepresentation (which the API recommends as a good starting point for user defined Representations). On #2, the incoming Representation is the request entity, so it will probably be org.restlet.resource.InputRepresentation. - Original Message - From: Jim Alateras [EMAIL PROTECTED] To: discuss@restlet.tigris.org Sent: Tuesday, September 4, 2007 10:17:42 PM (GMT-0500) America/New_York Subject: Resources and Representations A couple of questions regarding Resource and Representation. 1. I am thinking of creating an AtomFeedRepresentation by extending StringRepresentation. Is this the best approach? 2. When Resource.post(Representation) is called on my resource instance how does the restlet framework work out the Representation type that it will pass across? For instance if i do a post with application/atom+xml media type what will be the Representation type that will be passed to the post method? cheers /jima
Re: Resources and Representations
Hi, On #1 : I share Rob's point of view. on #2 : when using an HTTP server extension such as Jetty, Simple or AsynchWeb, all call classes derive from the com.noelios.restlet.http.HttpServerCall which converts the request entity into an InputRepresentation (have a look the method getRequestEntity). However, it's very easy to create a new Sax(or Dom)Representation from a Representation, since there is a constructor which accepts a Representation instance. best regards, Thierry Boileau On #1, I don't know much about Atom but if it's an XML type feed, I'd extend XmlRepresentation, SaxRepresentation, or DomRepresentation, or at the very least OutputRepresentation (which the API recommends as a good starting point for user defined Representations). On #2, the incoming Representation is the request entity, so it will probably be org.restlet.resource.InputRepresentation. - Original Message - From: Jim Alateras [EMAIL PROTECTED] To: discuss@restlet.tigris.org Sent: Tuesday, September 4, 2007 10:17:42 PM (GMT-0500) America/New_York Subject: Resources and Representations A couple of questions regarding Resource and Representation. 1. I am thinking of creating an AtomFeedRepresentation by extending StringRepresentation. Is this the best approach? 2. When Resource.post(Representation) is called on my resource instance how does the restlet framework work out the Representation type that it will pass across? For instance if i do a post with application/atom+xml media type what will be the Representation type that will be passed to the post method? cheers /jima
RE: Restlet wiki (was: Resources and Representations)
Hi all, I'm considering two options for this Wiki request: 1) Install a Wiki engine on the Restlet.org machine: this will need to wait until I migrate the machine to a new hosting service in December and until I have some spare CPU cycles :) 2) Use the Wiki feature of Java.net (http://wiki.java.net/bin/view/Main/WebHome). FYI, we have a pending request to join there (https://restlet.dev.java.net/). They use an infrastructure similar to Tigris.org (CollabNet) so a migration may be possible. Before we get a first-class Wiki, we could use the Documents files feature from Tigris to share and collaborate on files (text, HTML, PDF, etc.). I know it's a bit primitive also, but it is freely hosted and maintained by Tigris, which is nice. Before you can contribute, you need to be a registered member on Tigris and ask for an Observer role on the Restlet project: http://restlet.tigris.org/servlets/ProjectDocumentList Best regards, Jerome -Message d'origine- De : Piyush Purang [mailto:[EMAIL PROTECTED] Envoyé : jeudi 10 août 2006 22:53 À : discuss@restlet.tigris.org Objet : Re: Restlet wiki (was: Resources and Representations) Thanks John, for creating my suggestion into another discussion thread. I am glad that little piece wasn't missed. +1 JIRA would be great and once it is up and running we can start adding issue numbers directly into the changelog and every API change should, from then on, be first added to JIRA as an issue. On 8/10/06, Jerome Louvel [EMAIL PROTECTED] wrote: Ok, I've entered an issue to keep track of this request: http://restlet.tigris.org/issues/show_bug.cgi?id=150 Best regards, Jerome -Message d'origine- De : Chris Winters [mailto:[EMAIL PROTECTED] Envoyé : jeudi 10 août 2006 17:35 À : discuss@restlet.tigris.org Objet : Re: Restlet wiki (was: Resources and Representations) John D. Mitchell wrote: FWIW, the Atlassian folks give free licenses to open source projects for both Jira and their wiki, Confluence. +1, especially to Confluence in the near-term. JIRA in the longer-term, I think the issue tracking on tigris is a little... primitive. Chris -- Chris Winters ([EMAIL PROTECTED]) Lead Software Developer Vocollect Healthcare Systems CONFIDENTIAL, PRIVILEGED COMMUNICATION: This e-mail is private and intended for the addressee(s) only. It may contain privileged and/or confidential information. If you have received it in error you are not authorized to disseminate it in any manner; please delete it and any copies and reply to the sender that it was misdirected.
Re: Resources and Representations
Perhaps a WIKI on restlet.org with a general/open examples section would be great so that examples could be uploaded and discussions can be had on the uploaded examples.. I would then upload my solution to configuring components using an XML file (JAXB and handler classes). Chris could upload his example there... integrating a simple wiki with restlets would be a great example too!
Restlet wiki (was: Resources and Representations)
FWIW, the Atlassian folks give free licenses to open source projects for both Jira and their wiki, Confluence. Take care, John
Re: Resources and Representations
Jerome Louvel wrote: ... Agreed, the tutorial needs to be refocused. I'm considering writing a separate tutorial that will focus only on Restlet Applications, Resources and Representations, going through a more real life example. If Chris Winters wants to contribute his BookStore application to the project, maybe we can get this done faster :-) I need to justify my architecture decisions this morning, but I hope to have something a little interesting available by this afternoon. Chris -- Chris Winters ([EMAIL PROTECTED]) Lead Software Developer Vocollect Healthcare Systems CONFIDENTIAL, PRIVILEGED COMMUNICATION: This e-mail is private and intended for the addressee(s) only. It may contain privileged and/or confidential information. If you have received it in error you are not authorized to disseminate it in any manner; please delete it and any copies and reply to the sender that it was misdirected.
RE: Resources and Representations
Hi Piyush, I find that the Resource and its representations is a central part of the dissertation but the tutorial somehow doesn't bring that to the fore. Would you agree on that? I do :-) and there is a plan to fill this hole: http://restlet.tigris.org/issues/show_bug.cgi?id=118 The reason for this is that this part of the API was the hardest to define and stabilize. Also, the lack of Restlet Application abstraction forces users to manually build the whole server/container. This is not too hard but still it distracts people from the real goal which is to work with Resources and Representations. And I am still not convinced why Representation should extend Resource (We are talking API here)? This took me a while to get straight, so I understand that you are still confused. Shouldn't Resource have different Representations? Absolutely, they CAN have different representations. And if so shouldn't there be a mechanism of asking a resource it's representation (Or a representation builder that takes a resource and builds a suitable representtaion for it)? Resource.getVariants() does exactly that. Here is a snippet from a draft that I never sent maybe it brings out the question(s) better than the text I wrote above. Why is a Representation also a Resource? If I understand the dissertation correctly then a Resource has a Representation but not the other way around. And a resource may have different kinds of representations depending on the resource identifier that is used. REST says that both a Resource and a Representation are Data Elements. In addition, HTTP clearly gives URIs to representations via the optional Content-Location header. In the end, if you think about a world of Resources (as you would think about a world of Objects), then any concept/idea/thing that can be usefully identified is a Resource. So Representations are potentially Resources too which leads to the extension declaration between the Java interfaces. We already use this facility to support the Content-Location header for example: we simply check if the Representation.identifier property is defined. It seems like a resource is a very essential part of the RESTLET architecture but somehow in all the documentation that I have read incl. the tutorial somehow this message doesn't come through. I haven't seen any comncrete example. Agreed, the tutorial needs to be refocused. I'm considering writing a separate tutorial that will focus only on Restlet Applications, Resources and Representations, going through a more real life example. If Chris Winters wants to contribute his BookStore application to the project, maybe we can get this done faster :-) Best regards, Jerome
