cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira">
Subject Re: Multiple output streams best practices (was XMLForm & JSF)
Date Tue, 08 Apr 2003 22:01:16 GMT
> Well, since you took the time to reply I guess I'll jump into the
> details. I need to split the output of a single transform into two
> streams, to resolve two external requests.  
> The basic use case is HTML iframes, the specific use case is
> hierarchical forms.  Since HTML doesn't allow forms within forms we
> use iframes to contain them.  Currently we use an ugly JavaScript hack
> that copies some html out of the parent into the inner iframes.  We
> get away with this at the moment since it's all intranet and we
> specify IE.  Long run this has to go extranet and we have to handle
> this server side.  So, what I need is to run one transform and spit
> out two (possibly many) result sets to two match two different URIs. 
> Yes I could run many separate transforms on the same datasets, but
> there are two issues: 
> 1) These are very expensive transforms (for various reasons) and if we
> had multiple output streams that could catch the output data things
> would perform much better (and keep all the logic in one spot). In one
> case there is 18 different inner forms, running the transform 19 times
> would be a real pain even if all the data was cached.
> 2) You need to generate unique-ids to map the iforms to the contents
> and it would be very messy to have to cache this somewhere, though
> possibly flow might solve that.
> In any case, flow would have to be part of the solution, since you'd
> need some kind of ability to wait on the second request and wait on
> the first result simultaneously as it where (ie; continue with the
> output when the data becomes available...). 

I don't whether it would work for you (or how much work it would be to follow a similar 
approach) but the FragmentExtractorTransformer/Generator do something like this.

The Transformer stores a fragment from within the stream as an object in a transient 
store (whatever that is...) and passes an ID to the next stage. Then that ID is used by 
the browser to make another request to the server, which calls a pipeline beginning 
with the Generator, which simply gets the content from this transient store using the 
ID provided. So you can generate once, but serve two requests. The purpose of it 
was for serving HTML and SVG generated in one pipeline but consisting of two 
requests, but maybe you could use it, or something inspired by it. It is in the Batik 

Regards, Upayavira

now how much work you're prepared to do, but the 
FragmentExtractingTransformer(?) does this for inline SVG images. You use a 
transformer that writes part of its stream into an entry in the object model, 

View raw message