On 3/21/07, Grzegorz Kossakowski <gkossakowski@apache.org> wrote:
> Peter Hunsberger napisał(a):
> > On 3/20/07, Daniel Fagerstrom <danielf@nada.kth.se> wrote:
> >
> > Whatever the model is make it easily extensible; I think you want some
> > kind of class discovery mechanism here as well as on the expression
> > language side?
>
> Haven't thought about it but it's seems to be good idea. I'll consider
> it more attentively and share my thoughts. Do you have use cases that
> need such a discovery? Apart from flow passing some that to the pipeline
> as I think this should stay the same as it's now.
We sort of have a version of this in our code; we have a factory
implementation that discovers any class in a particular package so
it's not completely generalized (no Spring here, we started this with
Cocoon 2.3 or so) but it's pretty handy for simple lists of values and
even simple trees (we recognize an additional interface that allows
for building the hierarchy).
In our case, we essentially have a sort of
"ObjectModelWalkingGenerator" that makes it trivial to generate random
XML fragments (really SAX events); create a class with some standard
interface and bang, any pipeline that includes such a generator will
walk a class (perhaps determined by an argument to the generator) and
create name value pairs in some standard way (it's more general than
that but I think you get the idea)..
In our case we feed this into XSLT and avoid using any custom
templating or custom expression language, but really I think it's the
same thing in the end?
>
> > There's a set of use cases that use coupled output and input modules
> > you should be aware of; basically the pattern is to have a side
> > pipeline from flow using cocoon.processPipelineTo. This side pipeline
> > then runs and leaves some results hanging around via an output module
> > and the main pipeline then picks the results up via a corresponding
> > input module (eg. RequestAttributeOutputModule and
> > input.RequestAttributeModule). Our use case is forms validation via
> > Schemeatron where we create the result of the validation in the side
> > pipeline. Other people apparently use a similar pattern to do SOAP
> > processing.
> >
> > I can send you are flow script and pipelines for this if you want, or
> > it may all be outside of the scope of the changes you are making and
> > not matter?
> >
> > Whatever is done, I think we need a SOAP example that works with the
> > recommended implementation?
>
> Send these snippets relevant to the use of output modules. I would like
> to see how they used and then comment on this issue.
I don't have a SOAP example, here's a stripped down version of the
flow code for our Schematron evaluation:
function _validate( page, args ) {
var sourceURI = "run/_validate/"+page;
var destinationURI = "xmodule:request-attr:validate";
var resolver = null;
var destination = null;
try {
resolver = cocoon.getComponent(
Packages.org.apache.cocoon.environment.SourceResolver.ROLE );
destination = resolver.resolveURI( destinationURI );
var output = destination.getOutputStream();
cocoon.processPipelineTo( sourceURI, {}, output );
output.close();
if ( cocoon.request.getAttribute( "validationErrorLevel" ) == 0 ) {
return true;
}
}
finally {
if (destination != null) {
resolver.release( destination );
}
cocoon.releaseComponent( resolver );
}
return false;
}
Basically, we do a sendPageAndWait on a form and then run this
function after it returns to validate the form results. If the
function returns false we are going to reshow the page and we can grab
the errors from the validation pipeline and show them on the page
along with everything else (via aggregated XML from multiple
generators).
The key here is that you can run a pipeline in the middle of running
some flow logic and examine the results of the pipeline to determine
what the flow logic is going to do next.
This will probably raise more questions than it answers, but feel free
to ask away if you see a need...
--
Peter Hunsberger