Hi all, The Message's toString(), getEntityAsDom(), getEntityAsSax() and getEntityAsForm() are provided for a limited set of core Representations. Basically those available in the org.restlet.resource package, not requiring any extension JAR beside the JDK.
I agree that it is convenient to be able to call getEntityAsForm() several times without trouble. I've changed SVN trunk to now return the same representation instance when this method is called several times, the same for getEntityAsSax() and getEntityAsDom(). For other cases, it is always possible to use the request attributes map to store your converted entities, for example as JaxbRepresentations. Best regards, Jerome > -----Message d'origine----- > De : Rob Heittman [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 29 août 2007 03:50 > À : [email protected] > Objet : Re: Reusable representations > > > Thanks for sorting me out, Chuck ... > > > First, I'm not sure I understand why you'd call > > getEntityAsForm() if the params are in the URI. > > Retracted. You wouldn't. getResourceRef().getQueryAsForm() > is what one would use in this case, and it does not have any > destructive side effects on the Entity. I was just trying to > work through the implications of the transient/available > stuff that came up yesterday and constructed an example that > turns out to be largely bogus. Duh. I've just demonstrated > that despite being up to my knees every day in Restlet guts > lately, I also am a Restlet newbie! > > > First off, some messages can be really large and you'd > > rather stream them directly to a file rather than trying > > to cache them in memory ... > > Yes. For example, naively calling something like > getEntityAsDom() can indeed expose your application to a > brutal denial of service opportunity when someone starts > PUTting hundreds of MB of XML for fun and giggles. > > I also agree that it's hard to make any sort of > framework-level caching general enough to work in all cases > ... and if you make something that has cache tuning features > galore, most users won't be able to grok, let alone frob, all > the necessary features in order to get satisfactory results. > (cough) Hibernate. > > I guess the operational rule that probably applies here is > that a well-behaved Filter, Router, Guard -- or any other > intermediate Restlet other than a Resource or something that > serves up resources -- should work very hard to avoid > touching (even reading) the Entity. This is probably a good > rule both in terms of architectural style and also the simple > network reality -- as you point out, once you get the bits > out of the stream or channel, you can't put'em back. If an > intermediate Restlet has to touch the Entity, everything > downstream of it needs to be aware of any potential side > effects and how to recover from them (e.g. to get a cached > representation from wherever it has been stowed). If one is > building intermediate Restlets meant to be reusable without > downstream knowledge, this isn't an option. > > - R
