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