Fogelson, Steve wrote:

After reading the thread last week about "Objects versus branch", I went
back and read Witango's documentation concerning class files. I want to make
sure my class files aren't stepping on themselves (thread safe), so if you
don't mind I would like to ask a few more questions.

I couldn't find if class files are cached like taf files when the cache
variable is set. I have always assumed they were.

Ben talked about treating methods like functions and passing "parameters"
back and forth. This leads me to the next 3 questions:
Can you create request or user scoped variables within a class file? IE: In
effect passing vars back to the calling taf.


Yes

Can you reference request or user scoped variables within a class file?


Yes

Can you update request or user scoped variables within a class file?


Yes

I have assumed that you can reference custom scoped vars within a class
file, but that it is not advisable to create or update them. In my
applications they are used somewhat like domain scoped vars.

Are you supposed to use <@getparam> and <@setparam> to reference and update
"named method parameters" or is it ok to use <@var> and <@assign>? If it is
ok to use <@var> and <@assign>, why are there <getparam> and <@setparam>
tags?

If it is not okay to use request scoped vars in a class file, I have the
next 2 questions:
DB action results are a request scoped variable. Is this ok in a class file?

The Counter_Variable in a For Loop action is scoped request. Can they be
used in a class file?


In my opinion this is a Bug with Witango. The countervariable in a For Loop Action inside a method *should* be scope=Method. but you can't change it. This makes writing recursive functions a little more dificult, because you have to use a while loop with your own counter management.

It's not just recursive functions that you have to worry about... any nested methods could end up overwriting a local that another method was using. Stay away from request scoped variables inside of methods unless you want the behaviour of the method to mutate a "global" request variable like that.

I would suggest making your method obvious that it does such a thing...

for example, instead of calling a method "getCustomerInfo" and having that assign some customer information to local variables, it might be better if you called the method "assignCustomerInfoToRequest" or something similar that makes it obvious to you or anyone else who looks at your code that a mutation outside of the typical call / return is occuring with this method call.

You should still be very careful in how those Local/Request scoped variables are named as to not interfere with any other methods that have a similar behaviour.

/John

Thanks for taking the time to respond.

Steve Fogelson
Internet Commerce Solutions






________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf



________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Reply via email to