Wayne,

Let me start by saying that variable scoping comes down to a matter of keying. 
Meaning that each scope is defined by its key, and your question is really one 
of managing keys.

First, the user scope. Technically speaking, the user scope is not restricted 
to a domain. It is keyed to a session cookie which is automatically setup by 
the server. Web browsers will only send session cookies back to the domain from 
which they were set, and by domain, I mean http://{everything_in_here}/

It would be theoretically possible to set cookies which would apply to 
sub-domains (eg. *.domain.com) but this is not currently a function of the 
server. If there is some demand for this ability, I'll consider adding it.

One additional note on this topic, the default setting is to key the user scope 
to the cookie value alone, however it's not a bad idea to enforce the user <-> 
domain connection in many cases, and to do so, the user scope key would become: 
<@DOMAIN><@USERREFERENCE>

Second, domain scopes. Domain scopes are actually keyed to the "TeraScript 
Domain". However, since these are rarely setup, the default is the host and 
domain portion of the URL: http://{everything_in_here}/. You can use the 
domains.ini file to set up the server so that both hosts are considered the 
same domain. The domains.ini would look like this:

        [Domains]
        Mydomain_com_au=

        [Mydomain_com_au]
        www.mydomain.com.au
        abc123.mydomain.com.au

With that in place, you could assign domain$myVar at http://www.mydomain.com.au 
and then use that variable (@@domain$myVar) at http://abc123.mydomain.com.au. 
Internally TeraScript would see both URLs as being at the "Mydomain_com_au" 
TeraScript Domain.

I realize that this doesn't solve your problem, but I thought it would be 
helpful to know.

Using the tools currently available to you, you can simulate what you need 
using the custom scope.

One thing that you need to do to make this work is have a unique identifier for 
your user. Let's say your user is logged in and has user number 12345, which is 
stored in the user variable user_id (@@user$user_id). You can store data into a 
custom scope variable as such:

        <@ASSIGN scope="USERID@@user$user_id" name="myVar" value="myValue">

Now, by using @@user$user_id as part of the scope, I effectively created a 
system wide scope which is keyed to this user's user_id. Note that I needed to 
start the scope name with the text "USERID" because scope names must begin with 
characters. This variable is available server wide, because custom scopes are 
keyed to the scope name only, not the domain, cookie, or any other value.

Now, If you send your user to a different domain, all you need to do is somehow 
pass the user_id (in the link, post argument, or have the user login again). 
Once you know the user_id on the new domain, you can access the above variable 
with:

        <@VAR USERID<@VAR user$user_id>$myVar>

I hope that points you in the right direction. Let me know if you have further 
questions, I'd be happy to help.

Robert



-----Original Message-----
From: Wayne Irvine [mailto:[email protected]]
Sent: Sunday, November 06, 2011 10:32 PM
To: [email protected]
Subject: Witango-Talk: Var across multiple domains

An issue occurred to me over the weekend. You can have SCOPE=DOMAIN and the 
values are accessible to all users, and you have SCOPE=USER, whose values are 
accessible to a given user in a specific domain.

Is there a SCOPE value that is available to a given user, but across multiple 
domains?

So if I set:
<@ASSIGN NAME=loggedin SCOPE=???? VALUE='yes'> in domain 'www.mydomain.com.au'

the value would be accessible in domain 'abc321.mydomain.com.au'.

Failing this, is there a way of passing values to a sub domain without using a 
form and args?

Wayne Irvine

----------------------------------------

To unsubscribe from this list, please send an email to [email protected] 
with "unsubscribe witango-talk" in the body.



----------------------------------------

To unsubscribe from this list, please send an email to [email protected] 
with "unsubscribe witango-talk" in the body.

Reply via email to