Re: media type adaptor
Hi Tim, I didn't follow the ful discussion, but did you take a look to JAX-RS? best regards Stephan Tim Peierls schrieb: So, if we are back using runtime annotations, there is no particular type safety in play: Representation representXml(); would be as good (and even more compact) as: @Variant(xml) Representation toXml(); or if you want to be more explicit about the mediatype: @Variant(text/xml) Representation toXml(); -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1055994
Re: media type adaptor
I have looked at JAX-RS (and I know that it makes heavy use of annotations), but this was not about JAX-RS. My comment was specifically about the proposed use of a method-naming convention to convey meta-information in Restlet where it seems to me that an annotation-based approach would be better. Don't get me wrong: I very much like the simplicity of Restlet as it is, and I am not pushing for greater use of annotations in general. It's just that this particular feature seems like a mistake as it stands. --tim On Mon, Jan 26, 2009 at 3:50 PM, Stephan Koops stephan.ko...@web.de wrote: Hi Tim, I didn't follow the ful discussion, but did you take a look to JAX-RS? best regards Stephan Tim Peierls schrieb: So, if we are back using runtime annotations, there is no particular type safety in play: Representation representXml(); would be as good (and even more compact) as: @Variant(xml) Representation toXml(); or if you want to be more explicit about the mediatype: @Variant(text/xml) Representation toXml(); -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1055994 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1056391
Re: media type adaptor
On Tue, Jan 20, 2009 at 3:21 PM, Jerome Louvel jerome.lou...@noelios.com wrote: The other way would be to automatically generate Java source code based on those annotations to hard code the dispatching. But I'm not sure you want to go on this road which seems slippery to me, especially under Java 5 where it would require using the additional 'apt' tool. No, I didn't mean to suggest that. So, if we are back using runtime annotations, there is no particular type safety in play: Representation representXml(); would be as good (and even more compact) as: @Variant(xml) Representation toXml(); or if you want to be more explicit about the mediatype: @Variant(text/xml) Representation toXml(); I really prefer the simplicity of the first option. It is a naming style close the the JavaBean getter and setter methods, which are widely used and accepted. I haven't tried to flesh it out, but I was thinking along these lines (adopting Rhett's comment about names): @RepresentsVariant(type=XmlMediaType.class, lang=FrenchLanguage.class) Representation toXml(); where XmlMediaType extends MediaType and FrenchLanguage extends Language. But even without the type-safety aspect, I think there are two advantages to having something like this, with string arguments: @RepresentsVariant(type=application/xml, lang=fr-FR) Representation toXml(); instead of the simpler and more compact: Representation representXmlFr(); Advantage 1 is that the former doesn't restrict you to the extension mapping, as illustrated. Advantage 2 is that code comprehension tools are more likely to be able to work with the former than the latter, which relies on a convention outside of the get/set/is bean conventions. In addition, I think that it is easier to understand what the former is doing, even though the latter appears to be simpler. A casual reader might not realize that this method name is special, whereas it's hard to miss with the annotation. --tim On Tue, Jan 20, 2009 at 3:21 PM, Jerome Louvel jerome.lou...@noelios.comwrote: Hi Tim, Thanks for the frank feed-back. I do like type safety-ness very much but I don't see how the usage of annotations would help here. My understanding is that there are two ways to deal with annotations: 1. At compile time, using 'javac' (Java 6) or 'apt' (Java 5) 2. At runtime, if the annotation have been properly preserved In our case, we need extra info to be able to properly guess the variants and dispatch the resource thread to the matching method. This extra info can be either based on a method name convention or on a runtime annotation, but the dispatching has to be done dynamically, using Java reflection. The other way would be to automatically generate Java source code based on those annotations to hard code the dispatching. But I'm not sure you want to go on this road which seems slippery to me, especially under Java 5 where it would require using the additional 'apt' tool. So, if we are back using runtime annotations, there is no particular type safety in play: Representation representXml(); would be as good (and even more compact) as: @Variant(xml) Representation toXml(); or if you want to be more explicit about the mediatype: @Variant(text/xml) Representation toXml(); I really prefer the simplicity of the first option. It is a naming style close the the JavaBean getter and setter methods, which are widely used and accepted. Regarding the definitive inclusion in Restlet 1.2, it can be fully changed or reverted while we are in the milestone phase. Once we reach 1.2 RC1 however, those changes will become final, unless a serious security issue occurs. So, we could play with the new feature for a while and see how other users react. Meanwhile, we can definitely continue the debate! Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -- *De :* tpeie...@gmail.com [mailto:tpeie...@gmail.com] *De la part de* Tim Peierls *Envoyé :* vendredi 16 janvier 2009 17:10 *À :* discuss@restlet.tigris.org *Objet :* Re: media type adaptor While this is undeniably convenient, it deserves more thought and discussion before accepting as part of 1.2. I don't think it's a good idea as it stands. Item 35 of Josh Bloch's Effective Java (2nd edition) is Prefer annotations to naming patterns. One of the great strengths of Java is its type-safety, an important reason why Java is such a good choice for production web services. Naming patterns rely on conventions that are invisible to the compiler; they throw away the opportunity to enforce typing rules at compile time. The use of metadata (annotations), by contrast, lets the compiler work for you by catching type problems early. I'm talking specifically about using method-level annotations
RE: media type adaptor
Hi Tim,
Thanks for the frank feed-back.
I do like type safety-ness very much but I don't see how the usage of
annotations would help here. My understanding is that there
are two ways to deal with annotations:
1.
At compile time, using 'javac' (Java 6) or 'apt' (Java 5)
2.
At runtime, if the annotation have been properly preserved
In our case, we need extra info to be able to properly guess the variants and
dispatch the resource thread to the matching method.
This extra info can be either based on a method name convention or on a runtime
annotation, but the dispatching has to be done
dynamically, using Java reflection.
The other way would be to automatically generate Java source code based on
those annotations to hard code the dispatching. But I'm
not sure you want to go on this road which seems slippery to me, especially
under Java 5 where it would require using the additional
'apt' tool.
So, if we are back using runtime annotations, there is no particular type
safety in play:
Representation representXml();
would be as good (and even more compact) as:
@Variant(xml)
Representation toXml();
or if you want to be more explicit about the mediatype:
@Variant(text/xml)
Representation toXml();
I really prefer the simplicity of the first option. It is a naming style close
the the JavaBean getter and setter methods, which are
widely used and accepted.
Regarding the definitive inclusion in Restlet 1.2, it can be fully changed or
reverted while we are in the milestone phase. Once we
reach 1.2 RC1 however, those changes will become final, unless a serious
security issue occurs.
So, we could play with the new feature for a while and see how other users
react. Meanwhile, we can definitely continue the debate!
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 : tpeie...@gmail.com [mailto:tpeie...@gmail.com] De la part de Tim Peierls
Envoyé : vendredi 16 janvier 2009 17:10
À : discuss@restlet.tigris.org
Objet : Re: media type adaptor
While this is undeniably convenient, it deserves more thought and discussion
before accepting as part of 1.2. I don't think it's a
good idea as it stands.
Item 35 of Josh Bloch's Effective Java (2nd edition) is Prefer annotations to
naming patterns. One of the great strengths of Java
is its type-safety, an important reason why Java is such a good choice for
production web services. Naming patterns rely on
conventions that are invisible to the compiler; they throw away the opportunity
to enforce typing rules at compile time. The use of
metadata (annotations), by contrast, lets the compiler work for you by catching
type problems early.
I'm talking specifically about using method-level annotations instead of method
naming patterns in the case of Resource methods
related to variant representations. I'm not trying to take this line of
reasoning any farther. For example, while I'm not crazy
about allow* and handle*, at least that's in Handler, not Resource, and even
there Restlet *does* define the standard methods
(Get/Put/Post/Delete/Head/Options) explicitly.
--tim
On Fri, Jan 16, 2009 at 9:05 AM, Jerome Louvel jerome.lou...@noelios.com
wrote:
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(roottest/root,
MediaType.TEXT_XML);
}
public Representation representHtmlEn() {
return new StringRepresentation(htmltest EN/html,
MediaType.TEXT_HTML);
}
public Representation representHtmlFr() {
return new StringRepresentation(htmltest 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!
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1039001
RE: media type adaptor
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:cliff.binst...@coyotereporting.com] Envoyé : vendredi 16 janvier 2009 19:53 À : discuss@restlet.tigris.org 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:jerome.lou...@noelios.com] Sent: Friday, January 16, 2009 12:49 AM To: discuss@restlet.tigris.org 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:cliff.binst...@coyotereporting.com] Envoyé : jeudi 15 janvier 2009 19:31 À : discuss@restlet.tigris.org 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:jerome.lou...@noelios.com] 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:cliff.binst...@coyotereporting.com] 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
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:cliff.binst...@coyotereporting.com]
Envoyé : jeudi 15 janvier 2009 19:31
À : discuss@restlet.tigris.org
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:jerome.lou...@noelios.com]
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:cliff.binst...@coyotereporting.com]
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:taylor_co...@yahoo.com]
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
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:taylor_co...@yahoo.com]
Envoyé : jeudi 15 janvier 2009 22:03
À : discuss@restlet.tigris.org
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 cliff.binst...@coyotereporting.com
To: discuss@restlet.tigris.org
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:jerome.lou...@noelios.com]
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:cliff.binst...@coyotereporting.com]
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
RE: media type adaptor
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(roottest/root,
MediaType.TEXT_XML);
}
public Representation representHtmlEn() {
return new StringRepresentation(htmltest EN/html,
MediaType.TEXT_HTML);
}
public Representation representHtmlFr() {
return new StringRepresentation(htmltest 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:jerome.lou...@noelios.com]
Envoyé : vendredi 16 janvier 2009 14:36
À : discuss@restlet.tigris.org
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:taylor_co...@yahoo.com]
Envoyé : jeudi 15 janvier 2009 22:03
À : discuss@restlet.tigris.org
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 cliff.binst...@coyotereporting.com
To: discuss@restlet.tigris.org
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:jerome.lou...@noelios.com]
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
Re: media type adaptor
While this is undeniably convenient, it deserves more thought and discussion
before accepting as part of 1.2. I don't think it's a good idea as it
stands.
Item 35 of Josh Bloch's Effective Java (2nd edition) is Prefer annotations
to naming patterns. One of the great strengths of Java is its type-safety,
an important reason why Java is such a good choice for production web
services. Naming patterns rely on conventions that are invisible to the
compiler; they throw away the opportunity to enforce typing rules at compile
time. The use of metadata (annotations), by contrast, lets the compiler work
for you by catching type problems early.
I'm talking specifically about using method-level annotations instead of
method naming patterns in the case of Resource methods related to variant
representations. I'm not trying to take this line of reasoning any farther.
For example, while I'm not crazy about allow* and handle*, at least that's
in Handler, not Resource, and even there Restlet *does* define the standard
methods (Get/Put/Post/Delete/Head/Options) explicitly.
--tim
On Fri, Jan 16, 2009 at 9:05 AM, Jerome Louvel jerome.lou...@noelios.comwrote:
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(roottest/root,
MediaType.*TEXT_XML*);
}
*public* Representation representHtmlEn() {
*return* *new* StringRepresentation(htmltest EN/html,
MediaType.*TEXT_HTML*);
}
*public* Representation representHtmlFr() {
*return* *new* StringRepresentation(htmltest 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!
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:jerome.lou...@noelios.com] Sent: Friday, January 16, 2009 12:49 AM To: discuss@restlet.tigris.org 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:cliff.binst...@coyotereporting.com] Envoyé : jeudi 15 janvier 2009 19:31 À : discuss@restlet.tigris.org 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:jerome.lou...@noelios.com] 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:cliff.binst...@coyotereporting.com] 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
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 cliff.binst...@coyotereporting.com
To: discuss@restlet.tigris.org
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:jerome.lou...@noelios.com]
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
Noelios
Technologies ~ Co-founder ~ http://www.noelios.com
De :Cliff Binstock [mailto:cliff.binst...@coyotereporting.com]
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:taylor_co...@yahoo.com]
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
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,
Jerome 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:cliff.binst...@coyotereporting.com]
Envoye : mardi 13 janvier 2009 17:43
A : 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:taylor_co...@yahoo.com]
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=4447dsMessageId=1024594
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:taylor_co...@yahoo.com]
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=4447dsMessageId=1022252
