Thanks Scott
>Hey Dude,
>
>I think it all comes down to the matter of scalability. If your site is not
>too busy and you don't have any heavy SQL or Arrays to worry about - then
>likely you won't have problems. Going over old work can be a bigger monster
>than you want to think about sometimes, eh?
>
>If it is a busy site and performance is a concern - then I would think about
>all those Variables the Server has to constantly maintain when it doesn't
>have to.
>
>The only User Scope Variables I define are ones I need to maintain Profile
>and Security information for the user's session - and that's it. Everything
>else is explicitly assigned and called as Local, Method or Instance Scope or
>maintained in the Database. I do have some Domain Scope Arrays and some
>special XML files for global information which help to minimize trips to the
>database.
>
>I also stopped assigning most of my "User Preference" variables to User
>Scope and re-use MS Internet Explorer's 'Persistence' feature where you can
>define user specific information, much like a cookie, and re-use it
>client-side. 'Persistence' can store much more data than cookies can and are
>not limited to the same security rules, and is handy for things like
>populating last used values in a form - plus 'Persistence' information is
>stored as XML on the user machine :-)
>
>A couple points to consider:
>
>1.) - Depending on the purpose of your application, if your VariableTimeout
>is set too high (default 30 minutes) - then you are likely maintaining a
>hoard of unnecessary Variables long after your visitor has left your site.
>
>2.) - And if you have a hoard of unnecessary Variables to maintain - having
>the Server executing the Scoping Rules looking for a Variable without a
>Scope is going to take longer.
>
>Just a couple of my thoughts out load.
>
>Again, Andre's FAQ page is an awesome resource of information right now and
>gives you a lot of food for thought in respect to performance.
>http://www.stonesteps.ca/faq.html
>
>Cheers....
>
>Scott Cadillac
>http://xml-extra.net
>[EMAIL PROTECTED]
>
>VP, Research and Development
>Plus International Corp.
>604-460-1843
>[EMAIL PROTECTED]
>http://www.plusinternational.com
>
>Vancouver, BC, Canada
>
>Does your company have an Enterprise Information Portal? Check out Salsa at
>www.plusinternational.com/flash/salsa.htm
>
>----- Original Message -----
>From: "Web Dude" <[EMAIL PROTECTED]>
>To: "Multiple recipients of list witango-talk" <[EMAIL PROTECTED]>
>Sent: Tuesday, May 21, 2002 7:43 AM
>Subject: Witango-Talk: WiTango Speed
>
>
>> I read the info on how to max the speed when using WiTAngo and have
>> some general questions about scoping the variables.
>>
>> I have never defined the scope of variables unless I needed a
>> variable other then "user". I have around 40 sites and decided to go
>> back and change all variables and <@ASSIGNS> to include the scopes.
>> After 2 days of working on just one site, I decided to scrap going
>> backwards and trying to rewrite everything. (in the future I will
>> definitely scope all the variables.)
>>
>> My question would be -- should I worry about this? All the sites run
>> very well and fast. Most variables and <@ASSIGNS> are user scoped
>> (the default), but not explicitly defined as such. I do have a site
>> which is loading all info from MSSQL related to fonts, colors,
>> widths, heights, logos, etc and then being loaded into variables and
>> called on all pages. On this site I did define the scopes of
>> probably 95% of the site and have had no complaints.
>>
>> Waht are your thoughts guys and gals?
>>
>> Thanks!
>> --
>> ________________________________________________________________________
>> TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
>> with unsubscribe witango-talk in the message body
>>
>
>________________________________________________________________________
>TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
> with unsubscribe witango-talk in the message body
--
________________________________________________________________________
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
with unsubscribe witango-talk in the message body
