Sounds good Cliff, I think that the Tunnel and Metadata services are very flexibly and should let you achieve what you need. Let me know if something isn't clear. Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com
_____ De : Cliff Binstock [mailto:[email protected]] Envoyé : vendredi 16 janvier 2009 19:53 À : [email protected] Objet : RE: media type adaptor Jerome, I am using the standard content negotiation, and am declaring multiple variants. The issue is that I have LOTS of variants (HTML, XML, Excel spreadsheets, and more), and sometimes the variant I return might have NOTHING to do with the content list requested (Excel, for example, is not in the IE or FF content request list). I will look at the MetadataService rewrite, which might help. However I don’t currently have a “general” rule (which I think is what the MetadataService remap might accomplish), but the type-to-return rules are determined by the requested URLs. I will consider this, however, maybe I can (and should) make it more consistent. Thanks for the pointing these items out. I definitely will look at both the MetadataService and the TunnelService to see if I can better use the infrastructure. Cliff Binstock Coyote Reporting _____ From: Jerome Louvel [mailto:[email protected]] Sent: Friday, January 16, 2009 12:49 AM To: [email protected] Subject: RE: media type adaptor Hi Cliff, It seems like doing what you propose would overlap with the normal content negotiation which should be driven by client preferences. If you want to return the same representation as both "application/xhtml+xml" and "text/xml", if can simply declare the two variants and return the same "technical" representation for each one of them, either via the current if/else if approach or in the near future via the representXhtml() and representXml() methods. Also, in the MetadataService, the same extension (ex: "xml") can be mapped to several media types (ex: "text/xml" and "application/xml") so in this case, the representXml() method would match both. Regarding the browser nonsense, we did implement a solution in the TunnelService that can automatically rewrite the preferences based on the user agent name (see the "userAgentTunnel" property). Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com _____ De : Cliff Binstock [mailto:[email protected]] Envoyé : jeudi 15 janvier 2009 19:31 À : [email protected] Objet : RE: media type adaptor J�r�me, Some more thoughts … from experience … 1. Need a flag to determine if alternate representations are acceptable (Requester asked for HTML, but I don’t have that, and wish to return XML). 2. If alternate is acceptable, need a prioritized (ordered) list of acceptable variants (look for XHTML, then look for HTML, then look for XML).� You should probably have a default, but it should be easy to override. 3. If you feel like getting into the browser nonsense (and I’d understand if you didn’t), bypass/translate to another type.� For example, IE doesn’t behave kindly to XHTML return type.� Of course, any behavior here must be customizable (overridable). Cliff Binstock Coyote Reporting _____ From: Jerome Louvel [mailto:[email protected]] Sent: Wednesday, January 14, 2009 10:14 AM To: [email protected] Subject: RE: media type adaptor Hi all, We have a similar plan in the tube! "Faciliate Resource to Representation mapping" http://restlet.tigris.org/issues/show_bug.cgi?id=303 The idea is to dynamically dispatch the represent(*), acceptRepresentation(*) and storeRepresentation(*) to the more specific versions if available like: representXml(?) for an XML representation ("xml" being mapped in MetadataService like for file extensions) representJson(?) for a JSON representation ... This would handle the dispatching automatically while still allowing a manual dispatching by overriding the generic represent(*) method when more appropriate (and for backward compatibility). How does it sound? Best regards, J�r�me Louvel -- Restlet ~ Founder and Lead developer ~ <http://www.restlet.org/> http://www.restlet.org Noelios Technologies ~ Co-founder ~ <http://www.noelios.com/> http://www.noelios.com _____ De : Cliff Binstock [mailto:[email protected]] Envoy� : mardi 13 janvier 2009 17:43 � : [email protected] Objet : RE: media type adaptor Taylor, I have implemented a solution like this and I highly recommend it. I actually have taken it one step further and bound the routes (and the implementation) dynamically: there is very little Java code, mostly just XML-based configuration. In the cases where configuration does not make sense, then I have subclasses that provide an implementation as your message implies. I can tell you that you will want to pass in the request to the callback: you don’t always need it, but sometimes you need some contextual information (see previous post about wanting the original route URI, for example). Cliff Binstock Coyote Reporting _____ From: Taylor Cowan [mailto:[email protected]] Sent: Tuesday, January 13, 2009 7:12 AM To: [email protected] Subject: media type adaptor I'm new to restlets and would like some feedback from the community on some experimentation. Instead of if/else'ing through the list of variant types and calling the appropriate logic, I'd like reslets to do that for me. The example "MediaType" below is similar to the restlet version, except that each enumeration overrides a call back, for example, the text/html type calls back to handleTextHTML(). TEXT_HTML("text/html", "HTML document") { @Override public Representation callBack(VariantHandler arg0) { return arg0.handleTextHTML(); } }, The application developer then extends a resource from BaseResource, and implements the methods they'd like to handle. (like the AWT MouseEvent adaptors of old) The examples are not complete, I only implmented 4 media types. The BaseResource gets the media type, converts to the appropriate extended MediaType, and the invokes the callback. @Override public Representation represent(Variant variant) throws ResourceException { String mediaType = variant.getMediaType().getName(); return MediaType.value(mediaType).callBack(this); } So to handle HTML, the developer just does this: @Override public Representation handleTextHTML() { // here's where we respond to HTML clients. } http://restlets.s3.amazonaws.com/VariantHandler.java http://restlets.s3.amazonaws.com/BaseResource.java http://restlets.s3.amazonaws.com/MediaType.java ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1039005
