Allow sites to include variables (with token replacement) from the Omniture settings form

There was a minor typo in the text of the "Add another variable" button in the original patch

Below are some quick AB results:
> ab -n 1000 -kc 10 http://d7:8888/foo/bar/baz

It seems that this patch (not unsuprisingly) has no effect when no variables are added and it has very little performance impact on 95% of requests when there are variables. That last 5% though might take a hit.

I'm not sure where the tipping point might be so I'd love some feedback there.

That all said, I did notice one area where this needs work and that is when the "omniture basic" module is enabled. In that case, there are now two field groups named "variables" which is clearly not good. This can be solved by renaming the new variables fieldgroup to "custom variables" or something like that.

Thoughts?

--------------------------------------------------------------------------------

***** WITH THE PATCH (adding 0 variables) *****
Percentage of the requests served within a certain time (ms)
50% 191
66% 210
75% 225
80% 233
90% 249
95% 264
98% 277
99% 293
100% 317 (longest request)

***** WITH THE PATCH (adding ~10 variables where 5 use tokens) *****
Percentage of the requests served within a certain time (ms)
50% 211
66% 229
75% 244
80% 254
90% 274
95% 288
98% 305
99% 515
100% 538 (longest request)

***** WITHOUT THE PATCH *****
Percentage of the requests served within a certain time (ms)
50% 201
66% 217
75% 231
80% 241
90% 262
95% 279
98% 292
99% 299
100% 315 (longest request)

This patch names the new field group "Custom Variables" ... it also creates an _omniture_get_token_context() function so that other token functionality can be included elsewhere (ex: #1815866: Add token support for code snippets. ).

The AB test results have nt changed from #3

********** With Patch (10 vars with 5 tokens) ************

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  209  38.7    203     450
Processing:     0    3  34.7      0     450
Waiting:        0    3  34.7      0     449
Total:        148  212  39.7    204     450

********** Without the patch ************

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  202  36.2    197     311
Processing:     0    1  14.8      0     224
Waiting:        0    1  13.1      0     199
Total:        140  204  33.3    198     313

... setting to needs work as I found another weird issue with the table not being themed properly when omniture_basic is enabled

Turns out the weird theme issue was some stale cache data

the same as #4 with "variable" spelled correctly everywhere.

This patch just does some cleanup...

• improves the _omniture_get_token_context() function
• adds some extra comments
• creates a _omniture_variables_form function so the form can be reused (in context, for example)

I'd like to go ahead and commit this and given that only 2% of requests seem to see any performance difference I think we should be good to go. My reasoning is basically that there should be some sort of performance hit when using tokens and the more you use the worse it will be. That isn't really unexpected. A user can obviously choose not to use token replacements and they are not effected in that case at all.

Any final thoughts?

This is a re-roll of the patch in #9

Awesome!! Thanks for the review @lucascaro.

Committed: http://drupalcode.org/project/omniture.git/commit/7fad8ebf9fc5a09239f7e2...

@lucascaro ... feel free to give the patch at #1223462: Omniture Context intergation a review for even more awesomer flexibility