Orbeon Forms community mailing list

XPL for-each behavior

Classic

List

Threaded

5 messages Options

wreeder

XPL for-each behavior

I understand that the for-each element causes the execution of included processors once per item returned from the for-each's select attribute. However, I found today that if a processor inside of the for-each accesses an id from outside of the for-each, it also executes all processors used to create the referenced id. For example, I uses a sql processor outside of the for-each element to load data required by the for-each. I expected the sql processor to execute once since it is located outside of the for-each. However, it executes multiple times, once per item defined by the for-each's select attribute.

Is this expected behavior?

By the way, I was able to stop this behavior by adding a null-serializer after the sql processor to consume the id output of the sql processor before executing the for-each, and it stops the sql processor from executing multiple times. I can use this pattern elsewhere, but the behavior is subtle, and hard to find.

Thanks for any help on this issue.

-Bill

Steve Bayliss

RE: XPL for-each behavior

This does sound odd - I'd expect the SQL processor to be executed only once.

Do you have any debug attributes in any of your pipelines? This affects
caching behaviour I believe, maybe that's triggering it?

-----Original Message-----
From: Bill Reeder [mailto:[hidden email]]
Sent: 04 November 2008 22:20
To: [hidden email]
Subject: [ops-users] XPL for-each behavior

I understand that the for-each element causes the execution of included
processors once per item returned from the for-each's select attribute.
However, I found today that if a processor inside of the for-each accesses
an id from outside of the for-each, it also executes all processors used to
create the referenced id. For example, I uses a sql processor outside of the
for-each element to load data required by the for-each. I expected the sql
processor to execute once since it is located outside of the for-each.
However, it executes multiple times, once per item defined by the for-each's
select attribute.

Is this expected behavior?

By the way, I was able to stop this behavior by adding a null-serializer
after the sql processor to consume the id output of the sql processor before
executing the for-each, and it stops the sql processor from executing
multiple times. I can use this pattern elsewhere, but the behavior is
subtle, and hard to find.

Thanks for any help on this issue.

-Bill
--
View this message in context:
http://www.nabble.com/XPL-for-each-behavior-tp20332526p20332526.html
Sent from the ObjectWeb OPS - Users mailing list archive at Nabble.com.

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

wreeder

RE: XPL for-each behavior

I removed all the debug attributes, and the behavior is the same.

It looks like the for-each statement is not using the scope of the for-each block to determine what processors it runs in the loop.

Steve Bayliss wrote

This does sound odd - I'd expect the SQL processor to be executed only once.

Do you have any debug attributes in any of your pipelines? This affects
caching behaviour I believe, maybe that's triggering it?

-----Original Message-----
From: Bill Reeder [mailto:wreeder@delphi-tech.com]
Sent: 04 November 2008 22:20
To: ops-users@ow2.org
Subject: [ops-users] XPL for-each behavior

I understand that the for-each element causes the execution of included
processors once per item returned from the for-each's select attribute.
However, I found today that if a processor inside of the for-each accesses
an id from outside of the for-each, it also executes all processors used to
create the referenced id. For example, I uses a sql processor outside of the
for-each element to load data required by the for-each. I expected the sql
processor to execute once since it is located outside of the for-each.
However, it executes multiple times, once per item defined by the for-each's
select attribute.

Is this expected behavior?

By the way, I was able to stop this behavior by adding a null-serializer
after the sql processor to consume the id output of the sql processor before
executing the for-each, and it stops the sql processor from executing
multiple times. I can use this pattern elsewhere, but the behavior is
subtle, and hard to find.

Thanks for any help on this issue.

-Bill
--
View this message in context:
http://www.nabble.com/XPL-for-each-behavior-tp20332526p20332526.html
Sent from the ObjectWeb OPS - Users mailing list archive at Nabble.com.

--
You receive this message as a subscriber of the ops-users@ow2.org mailing list.
To unsubscribe: mailto:ops-users-unsubscribe@ow2.org
For general help: mailto:sympa@ow2.org?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Alessandro Vernet

RE: XPL for-each behavior

Administrator

Bill,

Bill Reeder wrote

It looks like the for-each statement is not using the scope of the for-each block to determine what processors it runs in the loop.

This is not an intended behavior. Said otherwise, it is a bug. Woo-how, it has been a long time since we have seen the last bug in the XPL engine :). When creating the objects that represent the pipeline in memory, we need to add a "Tee" to any output read from inside the for-each (unless there is one already). The Tee is keeping the read XML in a SAX store, so in case it is read again, it will be served from the SAX store instead of requiring the output it is connected to be re-read. I added this bug:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=311723&group_id=168&atid=350207

For now, the workaround is, like you did, to add a null-serializer outside of the for-each which reads the same output. In that case, the pipeline engine will "see" that this output is read by multiple processors and will add the Tee.

Alex

Erik Bruchez

RE: XPL for-each behavior

Administrator

All,

We have added the "Tee" processors mentioned in this thread, and this bug should now be fixed.

-Erik

Alessandro Vernet wrote

Bill,

Bill Reeder wrote

It looks like the for-each statement is not using the scope of the for-each block to determine what processors it runs in the loop.

This is not an intended behavior. Said otherwise, it is a bug. Woo-how, it has been a long time since we have seen the last bug in the XPL engine :). When creating the objects that represent the pipeline in memory, we need to add a "Tee" to any output read from inside the for-each (unless there is one already). The Tee is keeping the read XML in a SAX store, so in case it is read again, it will be served from the SAX store instead of requiring the output it is connected to be re-read. I added this bug:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=311723&group_id=168&atid=350207

For now, the workaround is, like you did, to add a null-serializer outside of the for-each which reads the same output. In that case, the pipeline engine will "see" that this output is read by multiple processors and will add the Tee.

Alex