Hi Marc, > ah ok, well it wasn't clear from the code/javadoc in the > TransformRepresentation class: > > getTransformer() is public, unsynchronized and has javadoc saying the > nested transformer is to be reused...
I've just committed some Javadocs clarifications. The TransformRepresentation can be reused when the source representation's content is always available (such as a DomRepresentation). But it isn't intended to be reused with other source representations. > hm, I think templating should even be able to produce XML > that is then fed into pipelines > > inside these pipelines custom xslt transformers/filters > should be active > (xslt is only one of the things you'ld like to do) [...] > Well, there is a bit of a mismatch (as well as some overlap) filters > work on request-response objects. Pipelines work on > (xml)representations. > > As such maybe the passed filters would help > decide/build/configure/parameterize the different active parts in the > pipeline, but the pipelining/content handling itself seems > distinct, no? I think this pipeline idea is worth pushing forward even if I'm not sure yet how it fits with the current Restlet design. For example, our representations tend to resolve their content lazily, when it is actually need for read/write operations (by a connector for example). The current equivalent of pipeline is to chain several wrapping representations on a source representation, one to transform, one to encode, etc. With this pattern it is harder to handle multi-output scenarii for example but for the rest it seems good no? > Haven't thought this through, and I was mainly thinking about > something > the pipeline architecture by itself would do as side effects > (e.g. save > a copy or summary of whatever it produced to some other server) > > But now that you make me think about the restlet context, I > do think a > multi-part kind of response would make sense, no? > Maybe there should be room for a BagRepresentation which is > essentially > a Map<String, Representation> ? > > There are surely use cases for this: > > - production of online produced zip-files, where the > different embedded > files themselves are dynamic (doesn't the odf format fit this bill?) > > - production of 'selfcontained-saveable' html with embedded images > through data: protocol serialization > > - ... These are definitely interesting use cases, feel free to create a new RFE for this. [...] > Maybe we should just have a mechanism to allow hooking-up > stuff on the > level of the request/response to be cleaned up after processing is > completed? Hmm, that wasn't clear to me. Maybe we should start some fresh discussion threads or discuss via RFE comments? This one is already becoming hard to follow for me. > I'm afraid JAXP is not a conclusive term in this ;-( > > inside jaxp there is sax, trax-sources and dom, and while there are > (somewhat) workable transitions between all of them, they are > distinct and only interoperate at the cost of handling the > impedance-mismatch > > plus, next to that there is at least stax to consider as well imho Maybe we could wait for JDK 6 and Restlet 2.0 to gain support for Stax? Best regards, Jerome
