To illustrate the new feature, here is the test resource class that I used in
the unit test:
public class AutoDetectResource extends Resource {
public Representation representXml() {
return new StringRepresentation("<root>test</root>",
MediaType.TEXT_XML);
}
public Representation representHtmlEn() {
return new StringRepresentation("<html>test EN</html>",
MediaType.TEXT_HTML);
}
public Representation representHtmlFr() {
return new StringRepresentation("<html>test FR</html>",
MediaType.TEXT_HTML);
}
}
No need in this case to override the constructor, to update the variants' list
or to manually handle the dispatching!
Best regards,
Jerome
_____
De : Jerome Louvel [mailto:[email protected]]
Envoyé : vendredi 16 janvier 2009 14:36
À : [email protected]
Objet : RE: media type adaptor
Hi Taylor,
I agree with you that this is an important core feature. What about if I tell
you that I have just committed the support for represent*() methods in SVN
trunk? :)
Here is the new paragraph in the Javadocs:
In addition, there is a simpler way to declare your variants and return the
matching representations. For this, you just need to add public represent*()
methods, where the '*' is replaced by a list of extensions in camel case. For
example "representXmlFr()" would declare two variants: one with the "text/xml"
media type and another with the "application/xml" media type. Both would
declare a {...@link Language#FRENCH} language. In addition, those methods must
return a {...@link Representation} instance and accept optional input parameter
of the following classes: {...@link MediaType}, {...@link Variant}, {...@link
CharacterSet}. Their value is provided from the selected variant to represent.
Note that if several media type or character set extensions are detected, they
will produce separate variants. However, several languages or encodings will
produce only one list for each defined variant. The list of supported
extensions and their matching metadata is provided by the application's
{...@link MetadataService}. If needed, this feature can be turned off by
calling {...@link #setDetectVariants(boolean)}.
Let me know if it works for you!
Next step is to extend this feature to accept*Representation() and
store*Representation() methods.
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 : Taylor Cowan [mailto:[email protected]]
Envoyé : jeudi 15 janvier 2009 22:03
À : [email protected]
Objet : Re: media type adaptor
Jerome,
that sounds good to me. The extent to which Restlets solves content negation
puts it head and shoulders above servlets and other web thingies.
My two cents is that's an area of priority, in comparison with all the planned
integrations (lucene, semweb, etc.). Also, Cliff's comments are good ones,
sounds like they've been doing a lot of this and went through the weeds already.
Taylor
_____
From: Cliff Binstock <[email protected]>
To: [email protected]
Sent: Thursday, January 15, 2009 12:30:52 PM
Subject: 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: discuss @restlet.tigris.org
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
� : discuss @restlet.tigris.org
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: discuss @restlet.tigris.org
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=1028648
