cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Culshaw" <>
Subject Re: Using the results of an aggregate part - order of execution.
Date Fri, 31 Jan 2003 09:22:46 GMT
I've been through this a million times (well er maybe not QUITE that many,
but near enough ) and I can't figure out how to do it without something
like an action pipeline as I suggested. The session action won't work in
this case because I need pipeline processing.

What I'm actually doing is roughly....

1) In APPLICATION, A within the AUTHENTICATION framework, click on a
button to 'do Task B in APPLICATION C.

2) In order to do task B in C I have to (i) call a remote system to
prefill an xmlform and then (ii) call up the xmlform action to actually
start off task B in C.

In addition the xmlform is the cocoon xmlform modified to bind to xml data
within the session rather than a bean (ie. the model is xml within a
session context rather than a compiled series of java beans).

No matter how much I juggle around with the components I still always come
up with the fact that the best place to implement the 2i step above is in
a pipeline, but I can't run the pipeline prior to step 2ii because step
2ii is an action that will be executed before the pipeline transforms I
need to achieve 2i. Ugh!

Can anyone suggest a better way because my pipeline action component seems
to be doing the job (ugly as it is)?

Maybe I should get into the Cocoon Servlet and start playing around with
servlet chaining??

> Tony Culshaw wrote:
>>What's interesting here is that an aggregate still does the cocoon
>> thing whereby MATCHERS ACTORS and SELECTORS are executed FIRST even
>> down through the aggregate parts (ie. internal pipelines) and then and
>> only then is the pipeline processor assembled with GENERATORS (inc
>> aggregators),
>>TRANSFORMERS and SERIALIZERS. The processor is then executed. This is
>> one of the biggest hurdles to overcome for anyone starting out with
>> this framework in terms of understanding.
>>This ultimately means that (in this example) any attempt to modify
>> session contexts in a part1 TRANSFORM of an aggregate will not be
>> visible by a part2 ACTION because the part2 ACTION is excecuted BEFORE
>> the part1 TRANSFORMER.
> I have not seen start of this thread... But I guess you are talking
> about session-fw here and its session transformer.
> You want to first invoke session transformer and then some action and
> then something else, but it rightly does not work this way.
>>To summarise in pseudo sitemap code...
>>  <part1 src="cocoon:/part1/>
>>  <part2 src="cocoon:/part2/>
>>    <action1/>
>>    <transform1/>
>>    <action2/>
>>    <transform2/>
>>The order of execution of components above will be action1, action2,
>> transform1, transform2.
>>Maybe the forthcoming flow stuff will help here, but I'm not sure.
>>However, there is another solution, but it involves a writing an
>>additional component and may be viewed by cocoon purists as a hack:)
> It's a hack not only by purists's views! Correct solution here is to not
>  use session-fw transformer but session-fw action. Thus, everything you
> want to do before invoking the pipeline will be done ... well ... before
>  invoking the pipeline, and no hacks like this will be required.
> Another IMHO brought to you by... :)
> Vadim
>>We (the company I'm currently contracting to) intend to release as a
>> block a number of utility components, one of which is a Pipeline
>> Action. This may upset some Cocoon purists but it is an action which
>> calls a pipeline (effectively a new http request back into the
>> framework).
>>This allows the called pipeline to FULLY execute (including transfomers
>> which may update session contexts), prior to whatever follows in the
>> rest of the caller's pipeline.
>>The only issue (if it is an issue) is that the result of the called
>> pipeline , ie. the serialized output, is discarded. This doesn't matter
>> if the only desire is to upadet th econtents of a session context.
>>I'll try and get a sample out in the next few nights if anyone's
>> interested.
>>Also, if anyone thinks this is really bad cocoon please let me know - I
>> guess it could be open to abuse.
> --------------------------------------------------------------------- To
> unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message