Re: Using the results of an aggregate part - order of execution.

[Vadim Gritsenko]

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

<aggregate>
<part1 src="cocoon:/part1/>
<part2 src="cocoon:/part2/>
</aggregate>

<part1>
<action1/>
<transform1/>
</part1>

<part2>
<action2/>
<transform2/>
</part2>

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]