Tony Jorgenson wrote:
> What I would like to do is have the "action" element both select a > new page, and also select an action for my java processor to > perform.
> My problem is that when the "home" page forwards to the "facelist" > page, it appears that the action list is interpreted before the > "facelist" page is even displayed. In fact, according to the traces > in the orbeon studio, the "facelist" page goes into an infinite loop > as follows:
Yes, this is correct. In a given page, actions are always executed before the model and view are executed. Model and view may not even be executed if the action result redirects to another page.
What is happening here is that:
1. Your first page sets "/context/action" of your XForms instance to the value "face-list".
2. The second page, "facelift", receives this XForms instance.
3. The <action when="..."> element tests on this and basically does a no-op with the XForms instance (copies it on itself), and then goes back to the same "facelist" page, which interprets the action again, etc.
If you don't want the action to be executed right after the forward to the second page, just don't set a value for the action in the XForms instance in the first place, i.e. don't do:
<xu:update select="/context/action">face-list</xu:update>
If instead you want the action to be executed but don't want an infinite loop, clear the action element before forwarding again, i.e.:
<result page="facelist">
<xu:update select="/context">
<xu:copy-of select="document('oxf:instance')/context/*"/>
</xu:update>
<xu:update select="/context/action"/>
</result>> So, it looks like the action list is being executed before the face > list is displayed. If the instance contains data that matches an > "action" for the page, it is executed immediately, which results in > the instance being copied and forwarding back to the page, where it > happens all over again. Is this expected behavior?
Yes. You create a loop, so the loop executes ;-)
> Even if the action list was executed before the display, I would > still expect that this occurs only once.
Then you would have to think about a built-in mechanism to prevent such behavior, which is not necessarily trivial. I tend to think it's better not to setup the conditions for a loop in the first place, because that keeps the behavior simple.
-Erik
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
orbeon-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
