Bill, I think this was covered, but you can think of a domain scoped TCF as the same as a cached TAF - that's because Witango largely sees it that was as well. When you run a TAF you can safely use the request scope in that one execution - even if others are also using that same TAF. In the same way, when you call a shared scope TCF, you can safely use the method scope inside of that method, even if other calls are also processing.
The kind of interesting thing is the instance scope. This now becomes a personalization of that specific instance of the TCF. This usually isn't too useful, but you could, for example use the instance scope to count how many times a method was called, but record the longest execution time of all calls, or some other purpose which would be useful to all users of the method. Robert -----Original Message----- From: Bill Conlon [mailto:[EMAIL PROTECTED] Sent: Friday, December 10, 2004 2:08 AM To: [EMAIL PROTECTED] Subject: Re: Witango-Talk: Objects versus branch Thanks everyone for your insights. Can I just ask for clarification on one thing -- object instantiation in a shared scope. Robert, it sounds like you run TCFs in a shared scope (such as application or domain) so the Object is created only once. For example, an init.taf might set up the class files for a domain: <@ASSIGN NAME="myObject" SCOPE="domain" VALUE="<@CREATEOBJECT TYPE='tcf' OBJECTID='MyObject.tcf'>"> Then within various appfiles you will invoke the methods: <@CALLMETHOD OBJECT=@@domain$myObject METHOD='foo(1,"test")'> So there is a single object instance, but the method can be called any number of times by this and other appfiles. Is my understanding correct? If it's correct, then how do you handle re-entrancy issues, method scope? thx. On Thursday, December 9, 2004, at 04:38 PM, Customer Support wrote: > The only thing that should be added is that unscoped variables can be > a performance hit. > > When an unscope variable is referenced the server starts looking for > the variable in the different variable stores ([Method then Instance > then] Request then User then Application then Domain then System). > Custom scopes fall outside of the Witango scope hierarchy; therefore, > only explicitly specifying the scope when returning the variable > allows Witango Server to find the variable. Cookie scope is also not > searched when no scope is present, though it does sit at the same > level in the scope hierarchy as user scope. > > We recommend that you always scope variables for optimum performance. > If you must use variables without scopes do not put them in large > loops (@FOR, @ROW, @WHILE, FOR Action WHILE Action). You will see a > performance difference when compared to scoped variables in loops > proportional to the number of iterations of the loop and the size of > the variable store in each scope. > > Witango Support > > On 10/12/2004, at 10:53 AM, Robert Shubert wrote: > >> >> >> 1. Scope. Can Objects be instantiated just once (say in application >> or domain scope) and used safely? It looks to me like you really >> should instantiate everything in request scope to avoid getting >> clobbered by another thread. >> >> I love objects and scope... I always name my object variables a little >> unique, and call them without a scope. This allows me to create an >> object in various scopes for various reasons: request or user when I'm >> developing, domain or custom when I'm in production. You can also >> beta-test on your production environment by leaving your production >> tcf >> in domain/application/custom and loading your beta tcf into >> request/user. Witango 5.0+ is a pro at managing TCFs in all scopes, >> and >> higher level scopes can really make them fast/easy to use, providing >> ever present functions akin to a custom tag. Just watch out how/when >> you >> purge/rebuild the higher scopes, you can pull a TCF out from under a >> running request. >> >> 2. Memory. Is each instantiated object a copy of the class file? It >> seems like application memory use would then be proportional to >> requests, whereas with branch/return application memory use is fixed >> (assuming cached) and data memory is proportional to the number of >> session. >> >> This is true, an application/domain level tcf would use about the same >> memory as a branched taf, and user scope would compound in the user >> var >> space for each user. >> >> 3. Performance. Does anyone have an idea of the extra burden placed >> on the server to manage object instantiation (for example, if TCF must >> be copied with each <@CREATEOBJECT>) >> >> It is very minor. There's effort with both of your methods, and both >> are >> very minor. I was once told that the way Witango handles TCFs (only, >> not >> other objects) is so close to a normal TAF that the decision on >> whether >> to use them or not should be made solely on the principles of >> programming. A more object orientated program design is good in many >> ways. HOWEVER, the use of TCFs is not truly objective, so beware of >> the >> pitfalls. >> >> Thanks. >> >> bill >> >> ______________________________________________________________________ >> __ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> >> ______________________________________________________________________ >> __ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
