Re: Representation<T> and Entity<T>

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 10 Apr 2007 13:26:03 +0200

Jerome Louvel wrote:
> Paul,
>>> @Method
>>> public Entry postEntry(@Input InputStream data, @MediaType
>> String type) {
>> How would one return the media type, language, or content location?
> If the Entity class can be modified:
> public class Entity {
> @MediaType
> public String getType() {...}
> @RedirectRef
> public URI getContentLocation() {...}
> }
> Otherwise:
> @Method
> public @Metadata(mediaType="text/foo", language="en") Entry
> postEntry(@Input InputStream data, @MediaType String type) {
> or
> @Method
> public @MediaType("text/foo") @Language("en") Entry
> postEntry(@Input InputStream data, @MediaType String type) {

IMHO this puts more work on the developer. They have to create their own
code for some very common cases.

>> In the above example I do see how the @MediaType makes it easier for
>> developers or that it adds any value to the API. A Java class will do
>> just fine, for example:
>> public Entry postEntry(@Input InputStream data, MediaType type)
>> And MediaType can provide support for getting access to parameters on
>> the media type.
> I do see the value in the MediaType class. There is a very similar one in
> the Restlet API. But I don't think this class should be mandatory for POJOs
> annotated with the JSR API. I would go even further: no class specific to
> JSR 311 should be mandatory for a proper usage of the annotations. So, it
> should be possible to get the media type as a String.

I agree. This is possible with the existing API proposal.

> As for the MediaType class, I would prefer to see it directly added to the
> JDK (in rather than in this JSR so that other APIs and JDK classes
> could benefit from it, like the URLConnection class.

Yes, if only we could :-) In the shorter time-frame we may be able to
get some sharing between Servlet and this API, which could in time get
put into the JDK. I think it is worth pursuing.

>>> Note that @Input is a specialized version of
>> @Representation pointing to the
>>> representation received as request entity.
>> It seems like we are converging on a solution as Input/Output is very
>> similar to Consume/Produce.
> Indeed :) The advantage of @Input/_at_Output is that they can specify more
> constraints (language, character set, etc.) than the
> @ProduceMime/_at_ConsumeMime annotations.

Yes, I like the idea of including language and character set (i do have
a preference for avoiding field names in annotations for the common cases).


| ? + ? = To question
    Paul Sandoz