On Apr 10, 2007, at 10:38 AM, Jerome Louvel wrote:
>>>
>> None of those helps when the return type can't be modified and the
>> media type isn't know in advance.
>
> In this rather unlikely case, it could simply rely on a wrapper
> POJO that
> would get annotated and would know how to "dynamically serialize" the
> wrapped POJO.
>
Its not an unlikely case, see APP, WebDAV, Amazon S3 etc.
>> I like the idea of being able to specify additional metadata like
>> language declaratively but you do run into a problem with annotation
>> syntax: as soon as you have more than one field in an annotation you
>> are forced to include the field names even when only specifying the
>> value of one field where all the others have defaults. E.g. with one
>> field you can write:
>>
>> @MediaType("text/foo")
>>
>> with two you can write:
>>
>> @MediaType(mediaType="text/foo", language="en")
>> or
>> @MediaType(mediaType="text/foo")
>>
>> but you can no longer write @MediaType("text/foo").
>>
>> You can always add more single field annotations but then you get an
>> explosion of annotation classes.
>
> In my the version of the API I described, I identified only 15
> annotations:
> - Representation, Input, Output
> - Resource, Param|Context, Method, Status, Metadata
> - MediaType, Language, CharacterSet, Encoding, Expires,
> LastModified, Tag
>
> We may need a couple of enumeration, too. That seems far from an
> explosion
> ;)
>
I think you missed my point. Adding additional properties to an
annotation requires slightly different syntax even when those
additional properties have default values.
BTW, in other threads you've already suggested a number of additional
annotations (e.g. ParentRef, RedirectRef, @Location, ContentLocation,
Context) - as we explore use cases I'm sure that number would grow ;-).
Marc
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s