Loop / ForEach Controller should expose a variable for current iteration

[asfimport]

@pmouawad (Bug 61802):
When I introduce those components, newbies don't understand why we don't expose OOTB this information which is very useful in many cases. Workaround is to use a Counter but why ?

I propose to name variable :

• _jm_<controller name>_it

If I missed an element that should also do, please update.
Thanks

OS: All

Blocks:

• Improve testing of Bug 61802 #5008

[asfimport]

@pmouawad (migrated from Bugzilla):
Author: pmouawad
Date: Tue Nov 28 07:11:35 2017
New Revision: 1816519

URL: http://svn.apache.org/viewvc?rev=1816519&view=rev
Log:
#4606 - Loop / ForEach Controller should expose a variable for current iteration
#4606

Modified:
jmeter/trunk/src/components/org/apache/jmeter/control/ForeachController.java
jmeter/trunk/src/core/org/apache/jmeter/control/LoopController.java
jmeter/trunk/src/core/org/apache/jmeter/util/JMeterUtils.java
jmeter/trunk/test/src/org/apache/jmeter/control/TestLoopController.java
jmeter/trunk/xdocs/changes.xml

[asfimport]

@pmouawad (migrated from Bugzilla):
2 remaining things before closing this Bugzilla:

• Documentation
• JUnit or Spcock Spec for ForEachController
• Possibly refactor LoopController tests which are not very readable

[asfimport]

@pmouawad (migrated from Bugzilla):
(In reply to Philippe Mouawad from comment 2)

2 remaining things before closing this Bugzilla:

• Documentation
• JUnit or Spcock Spec for ForEachController
• Possibly refactor LoopController tests which are not very readable

PRs welcome :-)

[asfimport]

@pmouawad (migrated from Bugzilla):
Author: pmouawad
Date: Wed Nov 29 07:36:35 2017
New Revision: 1816602

URL: http://svn.apache.org/viewvc?rev=1816602&view=rev
Log:
#4606 - Loop / ForEach Controller should expose a variable for current iteration
Document exposed variable
#4606

Modified:
jmeter/trunk/xdocs/usermanual/component_reference.xml

[asfimport]

@pmouawad (migrated from Bugzilla):
Fixed in 4.0.
Create #5008 for remaining work.

[vlsi]

@pmouawad , sorry for pinging you here, however, I'm trying to figure out the use cases for the added feature.
Unfortunately, I do not see end-to-end use case, so it is hard to understand when it would be useful.

At the same time, the feature adds CPU-intensive code (it allocates memory on string concatenation to build variable names): #5875 (comment)

Even though we could try removing the allocations (e.g. cache the output of org.apache.jmeter.util.JMeterUtils#formatJMeterExportedVariableName instead of computing it on each iteration), it would be great to know the use-cases.
Caching is not possible in default implementation of the interface, so it would require every implementation of IteratingController to implement its own cache, which is sad.

Alternative implementations could be:

• Add iterator variable name configuration property, so users could configure variable names they like. Then, if user does not use iterator variable name, they do not get the penalty. Of course, it would need to update the UI, however, then users would get more chances to discover the feature
• Implement lazily-computed variables #5928
  Provide ability to expose "compute on demand" properties. Then the looping controllers could expose the variable just once, and it would request the current value from the controller when user requests it

WDYT?