cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Unified expression handling and unified object model
Date Wed, 21 Mar 2007 15:04:54 GMT
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.

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

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/


Mime
View raw message