Forum Discussion
AlexS_yb
Cirrocumulus
CirrocumulusScope of variables when using call
Hi I have some irule code that looks like in one file MyLib_v1.0 proc process_URL {} { log local0. "process_URL: Enter" if { [ACCESS::session exists] && [ACCESS::session exists -state_allow -...
The proc does not inherit the variables from the caller. It will inherit all static variables and functions eg HTTP::path, but there are two ways to allow these variables in the procedure - either send them as calling variables, or use upvar.
Sending them as variables is more dependable - you don't need to worry about naming or suchlike but you can end up sending a lot of information. Add this to the procedure eg
proc process_URL {var1 var2 var3 {optionalvar "default value"} } { ... }You can also only have a single variable but make it a list.
Upvar depends on naming of variables to import a specific variable into the proc scope. Very useful if you want to modify the original variable, but open to errors if the variable doesn't exist or suchlike
AlexS_ybCirrocumulus
CirrocumulusThank you a very details and very usefil example
You talk about not using proc's
My need is to do the same thing (steps say 5 which includes a test ) in multiple places on a big switch statement based upon uri.
I can't group the URI together to write this code once and i don't want to duplicate it many times so i thought a call would be the way to do it.
you allude that there are better ways to do it. how would you do that ?
Kai_Wilke
MVP
MVPHi Alex,
Could you please write some pseudo code how the switch statement looks like and where the proc should be executed?
In most cases, you could probably devide your code structure in two destinct parts, the first part parameterizes settings based on conditions (aka. Switch statement assigns variables) and a second part reads parameters and then executes code conditional. This is probably the most used technique...
Instead of using [call] procedures you could use [eval] based macros. The difference between those two is that the [eval] macros are executed in the same execution level and can natively access the varibale from the caller. This is actually a slightly rare used technique...
There are many more options available to avoid the use of TCL procedures. It all depends what you are trying to achive...
Cheers, Kai
- AlexS_yb
Hi
Pretty simple switch
based up uri and then it
sets pools or makes calls (sso hooks - I had an old sso I had to attach to)
But must of the work is done in the switch.
Thinking about it yeah I could actually just set switchs and process it at the end.
eval macros - do you have a link to these and how they work, sound interesting
A
- Kai_Wilke
Hi AlexS,
> Thinking about it yeah I could actually just set switchs and process it at the end.
Inline code (even redundant code is far more effective within TCL), so yeah try to avoid [proc] as much as you can.
> eval macros - do you have a link to these and how they work, sound interesting
Below is an example of [eval] macros.
when RULE_INIT { set static::my_code_to_execute { # Define your code which needs to be executed in many places... append my_x "" append my_x "W" append my_x "o" append my_x "r" append my_x "l" append my_x "d" } } when HTTP_REQUEST { set my_x "Hello" # Insert the code above into your code and execute it... eval $static::my_code_to_execute log local0.debug $my_x }Warning: Always define your macro code during RULE_INIT in a static::* variable (use unique names for unique macros). And execute the defined code as shown above. Avoid other [eval] usecases unless you understand the nasty side effects and security implications of [eval].
Note: The RULE_INIT event may be stored in iRule 1 and the HTTP_REQUEST event can be stored in iRule 2. You only need to attach the iRule containing the HTTP_REQUEST event to your Virtual Server. You can basically define global accesible code macros with the outlined technique...
Cheers, Kai