At 2002-May-10 7:03 AM, Dan Stein said the following:
>
>Seems I have sometimes used Userreference and sometimes userreferance
>argument in my growing application.
>
>I would think it is important to be consistent and use one or the other but
>not both.
Yes, I concur, use <@USERREFERENCEARGUMENT> in your links, forms, and JavaScripts and
events (onclick, etc)
>So which is best to use or are their times when one is needed instead of the
>other? Should I change them all to one or the other? Why do we have both?
We have both for people like me. With all due respect to my former employer,
EveryWare, I don't trust the USER scope. Period. Sorry. And I still don't use it. What
I do instead is to use the <@USERREFERENCE> as a column in a table I call the Session
table. Along with the time last used, I store information that I want to keep for the
session in this table. Effectively I'm using the database to store user scoped vars.
Where's there's too much information to be kept in this table, like a shopping cart,
I'll create another table linked to the session_ID of the session table.
The advantage is that Tango can crash, the user can get bumped around between
different Tango Servers - even on different machines - and lose their "state" on the
web site. It increases reliability at a slight expense of speed as I have to
recalculate or look up many of the user's settings or preferences from the database
when I need them. At the same time, I'm not wasting server memory for storing
variables that I may or may not use.
I _used_ _to_ have many problems with Tango Server's reliability, so this was a
strategy that I came up with at the time that solved the problem. It has other
advantages that I find useful which is why I continue to use this strategy, but it may
not be the best strategy for you or for your sites.
To summarise, I use <@USERREFERENCE> as the value used in the select from, and insert
into, the session table. <@USERREFERENCEARGUMENT> is used in the HTML and JavaScript
of the Results and include files for creating links and forms.
Anthony -
________________________________________________________________________
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
with unsubscribe witango-talk in the message body
