Execution order of generateXXX Functions for Processors with multiple outputs

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Execution order of generateXXX Functions for Processors with multiple outputs

Rene Single
Hi all,


I have a custom processor with multiple outputs A, B & C.

B relies on the output  of A.
C relies on the output of B & A.

I'm wondering if Orbeon can know about this dependency, or if I have to
take care of it myself ?

Say I define my outputs in the Processor in the order A, B, C, will
Orbeon know that for providing C it must run A & B first ?

Or is the order the generateXXX functions are triggered up to the order
in which the outputs are accessed in the calling pipeline ?

So if C is accessed before A and B, Orbeon will only run the generate
function for C of my processor, thus producing unexpected results if I
don't take care of above stated dependency in my implementation ?

If I have to take care of it, would that mean:

    - I need to implement some state in the processor indicating what
has already been done
    - depending on the state, trigger the outstanding actions from each
of the generateXXX functions (of course synchronizing these actions, so
that they are only triggered once)
    - sharing the state via calls to getState(contexthandler) and
setState(contexthandler, state) in the three generate functions ?


Thanks in advance for any pointers

René


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Execution order of generateXXX Functions for Processors with multiple outputs

Alessandro  Vernet
Administrator
Hi René,

The output of your processor will be read in the order in which the data is needed by the processor(s) those outputs are connected to. Say you have outputs A and B, with A connected to the 'config' input of and XSLT processors and B to the 'data' input of that same XSLT processor. In that case, you can be pretty sure A will be read before B, because when the XSLT processor runs, it will first need to read the stylesheet (== 'config' input).

But in general, you shouldn't assume any particular order. Often you are in a case where whatever output is read first, you need to do some work, store the result (a "state"), and read from that state when subsequence output are read. For this purpose, ProcessorImpl provides the methods setState() and getState(). You can find more about this on:

http://wiki.orbeon.com/forms/doc/developer-guide/api-xpl-processor-api#TOC-Processor-instance-state

Alex
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet