cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject Multiple output streams best practices (was XMLForm & JSF)
Date Tue, 08 Apr 2003 21:07:07 GMT
Bruno Dumon <> wrote:

> >  If we had his capabilities that would work also.  I've got another 
> > slightly similar problem where I've got to generate two 
> output streams 
> > and I'd love to have some Cocoon best practices (relative 
> to the 2.1 
> > code base I guess) for this, to date I'm not sure if there is a 
> > consensus?
> Just use the SourceResolver to resolve a cocoon:/ URI? 
> (preferably from an action, or flowscript equivalent, to keep 
> the publishing pipeline side-effect free).

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...). 

View raw message