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

[Tony Culshaw <to...@cultech.com.au>]

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.

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:)

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

[Tony Culshaw <to...@cultech.com.au>]

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...
>>
>><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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

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

[Vadim Gritsenko <va...@verizon.net>]

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org