>From an architectural purity perspective, I agree with you ... while I like
>and use the syntactic sugar provided by getEntityAsXXXX, the methods currently
>provided are a bit inconsistent (per our earlier discussion), don't cover
>every possible case, and don't lend themselves readily to user or SPI
>extension. It's a bit of a subjective exercise to choose which types of
>representations are "important" enough to warrant a sugar method in Message
>and which don't. And as Thierry pointed out, you can do something like what
>you describe already -- supply your own conversion or representation and call
>it directly against the entity.
I think I agree enough to maybe ban getEntityAsXXXX in our code and start
supplying some converter helper classes in our own code -- with, perhaps a
cache feature.
- Rob
----- Original Message -----
From: "Stanczak Group" <[EMAIL PROTECTED]>
To: discuss@restlet.tigris.org
Sent: Tuesday, August 28, 2007 2:20:26 PM (GMT-0500) America/New_York
Subject: Re: Reusable representations
Honestly I'm not sure adding getEntityAsXXXX() anything is a good idea
in the api. I find it confusing that those are there. If anything it
should be a wrapper like DOMEntityConverter.convert(r.getEntity()), or
something like that. That way you can add converters as extensions.
Seems it lends itself to making a getEntityAsXXX() for every type or
have people asking question, like I did with getEntityAsObject(). Maybe
this would also lend itself to adding in extensions for cache
implementations. But in the end, you could easily implement Pico into
your application and call a service on the single request passing in
username and password each time and not even use the Guard. This would
limit to one call to getEntity(). But I may just be talking and not
saying anything. I'm new to REST so you probably know way more about it.
