You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Sebastian Klamar <se...@tux.wh17.tu-dresden.de> on 2003/12/30 13:00:32 UTC
concatenate two pipelines (was on dev list: Re: Running Schematron validation from flow)
* Hunsberger, Peter [2003-12-29 21:45 +0100] wrote:
> Ok, figured this out: don't use copy, use processPipelineTo and use the
> xmodule as the target... So far so good, except I'm not seeing the
> result in the request attribute after I've written it.
>
> I might note that if this works we've sort of got the capabliity for
> dynamically composing pipelines in flowscript: run whatever pipeline
> you want to write whatever data into memory, later run a regular
> pileline to aggregate this in memory data with it's normal output....
Peter, could you be more verbose how to concatenate several pipelines
together with the help of the new xmodule?
I'm currently using the pair
WriteDOMSessionTransformer/SessionAttributeGenerator to pipe the output
of one pipeline into another one. This is not an elegant solution bc
it requires a session. Besides this, Vadim's comment for Bug #25517
suggests to kill the components I use.
FUP cocoon-user?
TIA -- Sebastian
A fullquote for history on user list:
> > Vadim Gritsenko <va...@verizon.net> writes:
> >
> > >
> > > Hunsberger, Peter wrote:
> > >
> > > >Is
> > > >there any existing in-memory writable source available for
> > > reuse? Any
> > > >hints on how to do this?
> > > >
> > >
> > > Try:
> > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25210
> > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25517
> > >
> > Thanks, that seems to be half the picture, but I think I'm
> > still missing
> > something: can I call a Cocoon pipeline using xmodule? I'm
> > getting the
> > error:
> >
> > "Cannot set XMLSerializer outputstream"
> >
> > Which would seem to indicate a problem with the output
> > stream, but since I've tried using the request-attr stream
> > from the samples and got the same error I assume it's
> > something to do with the input side of the equation?
> >
> > The sitemap fragment for the input data is straightforward enough:
> >
> > <map:match pattern="*/_validate/**">
> > <map:generate src="cocoon:/{/1}/requestdata"/>
> > <map:transform src="stylesheets/resolve_request.xsl"/>
> > <map:transform
> > src="cocoon:/{1}/validationTemplate/{2}"/>
> > <map:transform type="CTcheck"/>
> > <map:serialize type="xml"/>
> > </map:match>
> >
> > The flowscript looks like:
> >
> > var sourceURI = "xmodule:cocoon:run/_validate/"+collection;
> > var destinationURI = "xmodule:request-attr:validate";
> >
> > var resolver = null;
> > var source = null;
> > var destination = null;
> > try {
> > resolver = cocoon.getComponent(
> > Packages.org.apache.cocoon.environment.SourceResolver.ROLE );
> > source = resolver.resolveURI( sourceURI );
> > destination = resolver.resolveURI( destinationURI );
> > return Packages.org.apache.excalibur.source.SourceUtil.copy(
> > source, destination );
> > } finally {
> > if ( source != null )
> > resolver.release( source );
> > if (destination != null)
> > resolver.release( destination );
> > cocoon.releaseComponent( resolver );
> > }
> >
> > Where "collection" is a variable previously set that tells me
> > what collection of metadata I'm dealing with.
> >
> > Is this just a case of using the wrong protocol (If so what
> > would it be)? Do I perhaps need a version of Cocoon from CVS
> > and not the 2.1.3 release?
> >
> > One interesting thing to note is that the error is reported
> > as occurring at the "cocoon.releaseComponent( resolver);"
> > line of the flow script...
--
Die letzten Worte...
des Weintrinkers: "Der hat aber einen komischen Geschmack."
************************************************************************
PGP Key: 0x1E727CE6 / 9085 48BD 8332 4BFC D80C A6CF D162 20BB 1E72 7CE6
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Fw: RE: concatenate two pipelines (was on dev list: Re: Running Schematron validation from flow)
Posted by Sebastian Klamar <se...@tux.wh17.tu-dresden.de>.
Peter didn't see my cross post with the Follow-Up, so I'm forwarding his
answer from dev list:
----- Forwarded message from "Hunsberger, Peter" <Pe...@stjude.org> -----
> From: "Hunsberger, Peter" <Pe...@stjude.org>
> Subject: RE: concatenate two pipelines (was on dev list: Re: Running Schematron validation from flow)
> Date: Tue, 30 Dec 2003 09:54:31 -0600
> To: dev@cocoon.apache.org
>
> Sebastian Klamar <se...@tux.wh17.tu-dresden.de> asks:
>
> >
> > * Hunsberger, Peter [2003-12-29 21:45 +0100] wrote:
> > > Ok, figured this out: don't use copy, use
> > processPipelineTo and use
> > > the xmodule as the target... So far so good, except I'm not seeing
> > > the result in the request attribute after I've written it.
> > >
> > > I might note that if this works we've sort of got the
> > capabliity for
> > > dynamically composing pipelines in flowscript: run
> > whatever pipeline
> > > you want to write whatever data into memory, later run a regular
> > > pileline to aggregate this in memory data with it's normal
> > output....
> >
> > Peter, could you be more verbose how to concatenate several
> > pipelines together with the help of the new xmodule?
> >
>
> <snip/>
>
> I can try. In the flow you can do something like:
>
> var sourceURI = "cocoon:"+target_pipeline;
> var destinationURI = "xmodule:request-attr:tempstorage";
> var resolver = null;
> var destination = null;
> try
> {
> resolver = cocoon.getComponent(
> Packages.org.apache.cocoon.environment.SourceResolver.ROLE );
> destination = resolver.resolveURI( destinationURI );
> output = destination.getOutputStream();
> cocoon.processPipelineTo( sourceURI, {}, output );
> output.close();
> } finally {
> if (destination != null)
> resolver.release( destination );
> cocoon.releaseComponent( resolver );
> }
>
> This will cause Cocoon to run the "target_pipeline" and stash the
> contents in the request attribute "tempstorage" (in this case). Later,
> when you want to get at the data you can run a generator that pulls the
> data back out of the request attribute. In particular, the request
> generator will do the trick with the "generate-attributes" parameter if
> you don't mind getting all of the rest of the request data and having to
> parse some pretty long xpath to find the data:
>
> <map:generate type="request">
> <map:parameter name="generate-attributes"
> value="true"/>
> </map:generate>
>
> You can of course run as many of these arbitrary pipelines as you want,
> stashing the contents into as many variables as you want, and then use
> map:aggregate to aggregate all the data from all the attributes one by
> one or have a generator that just knows what attributes to look at all
> at once (or just grab all attributes as per the request generator).
>
> Note, that you can also grab the data back out of the output stream at
> the time it is generated and stash it in a flow variable. This can then
> be passed back into a pipeline as variable (though parsing it will
> require treating it as a nodeset if using it as XML -- no big deal).
>
> I'm not quite sure what to think of this approach overall, it seems to
> push the boundaries of clean Cocoon design. However, for us it makes
> running Schematron as a validator very straight forward, I can basically
> write a sendPageAndValidate function that returns a Boolean if the page
> is valid, so flow looks like:
>
> var valid = false;
> while ( !valid )
> {
> valid = _sendPageAndValidate( "run/_page/" + screen );
> }
> cocoon.sendPage( "run/_page/" + nextscreen );
>
> Each sendPage picks up any errors created by the previous validation
> pass and most importantly to us we have full access to the Cocoon
> pipeline within Schematron so we can cross validate data from one screen
> with data (already in our database) produced by another screen. The
> trick here is to have the validating pipeline run a simple transformer
> that looks for Schematron assert statements in the output stream and
> sets another request variable indicating what it found. You can then
> pick this back up in the flow function I gave at the top of this reply:
>
> if ( cocoon.request.getAttribute( "validationErrorLevel" ) == 0
> )
> return true;
> else
> return false;
>
>
----- End forwarded message -----
Sebastian
--
Dinge, die man nicht hören will, wenn man operiert wird:
»Ich wünschte, ich hätte meine Brille nicht vergessen.«
************************************************************************
PGP Key: 0x1E727CE6 / 9085 48BD 8332 4BFC D80C A6CF D162 20BB 1E72 7CE6
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org