Thanks a lot, Markus
On Thu, Apr 2, 2009 at 9:20 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> On Apr 1, 2009, at 7:11 PM, Tatu Saloranta wrote:
>
> On Wed, Apr 1, 2009 at 8:52 AM, Markus Kohler <markus.kohler_at_gmail.com>
>> wrote:
>>
>>> Hi Paul,
>>> Thanks for you answer!
>>> Yes I thought about the solution to convert it to another bean, and yes I
>>> don't like the idea ;)
>>>
>>> Ideally I would think that one would just annotate a generic Collection
>>> to
>>> be homogeneous and then Jersey/JAXB would do the rest for me :)
>>>
>>
>> Personally I think this is a transformation operation that does not
>> really belong in core JAX-RS.
>> Current data binding is geared towards data binding, with just minimal
>> tweaks (wrapping or not for xml lists etc), and no major structural
>> transformations. So this would be extension towards either specific
>> transformations, or more general transformation framework. I suspect
>> xslt for example could quite easily handle this.
>>
>> But it also sounds like a contribution that would be useful for
>> others. And it might be something that could be made to work at Object
>> level (instead of format), thus being reusable with multiple formats.
>>
>>
> Yes. Although perhaps in this case the format would be focused on
> data-oriented formats like JSON or YAML where i think developers want to
> spit out collections/maps in a way that is easy to consume by the client
> than if using XML.
>
>
> Like Paul mentioned, MessageBodyWriter could be used to do these
>> transformations as part of output process; and MessageBodyReader for
>> doing reverse conversion when reading.
>>
>>
> See the example (no source link yet sorry!):
>
>
> http://download.java.net/maven/2/com/sun/jersey/samples/entity-provider/1.0.2/entity-provider-1.0.2-project.zip
>
> on how to write a message body reader and writer.
>
> Paul.
>
>
>
>
> Also: if and when size is the concern, this is the case where
>> compression (gzip) is very very efficient and can mostly remove
>> redundancy. So gzip filter should solve sparseness, if that is the
>> main concern (which some CPU usage expense, i.e. it's likely to be bit
>> slower).
>>
>> -+ Tatu +-
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>