Variables per application without using global variables

[robydago]

I’m just sharing how I’ve ended up managing variables that must be local to an application, but accessible from every local code (in events, buttons, etc.)

I’m using Programming > Attributes.

But to avoid to manually creating them (the SC IDE interface slows down this process), especially if have more than one or two, I just create a single attribute with the name “a”.

Then the first time I need to populate a specific attribute, I write something like this in the code:

{a}[‘myname’] = “myvalue”;

I can create and then access directly in the php code as many {a}[‘xxx’], {a}[‘yyy’], etc as I need, with just one “a” attribute created via Programming > Attributes.

AFAIK the only limitations are:

• in a grid app SQL, the “{a}[‘myname’]” syntax cannot be used, so in that case a specific attribute must be created, e.g. {myname} - note that in form app sql attributes cannot be used at all
• in some types of applications, before being able to create any “{a}[‘xxx’]”, the {a} attribute must be initialized as an array via “{a} = array();”.

[Kleyber_Derick]

@robydago very good approach!! I do a little different, but with the same results. I do this, in onLoad (if it is a grid):

[tk] = new StdClass;

[tk]->client_id     = {ds[0][1]};
...
...

So, I only define the tk variable in Programming → Attributes and I can use this in all places of my system.

It can be used in your login too, to populate a variable which can be accessed in every part of your app.

[robydago]

@Kleyber_Derick

so ti seems we are using the same approach and the only difference is that I use the attribute as a multidimensional array, while you use it as an object.

Just a couple of notes:

attributes can be accessed as [attribute_name]!? I didn’t know. I thought the only possible syntax was {attribute_name}.

Basically my question is: are you sure you’re using the attribute? With the [xxx] syntax I think SC wil create it automatically as a Application → Global variable.

I’m using attributes because my goal here is to have variables local to each application so that there’s no overlap.

[Kleyber_Derick]

@robydago

attributes can be accessed as [attribute_name]!? I didn’t know. I thought the only possible syntax was {attribute_name}.

Yes it can.

@robydago

Basically my question is: are you sure you’re using the attribute? With the [xxx] syntax I think SC wil create it automatically as a Application → Global variable.

Yes, I use here to replace the [usr_login] global variable and I had no problems with it.
The detail is: I configure [xxx] variable this way (even it is in Portuguese, but I think you will understand):

[robydago]

@Kleyber_Derick

in SC, attributes are not global variables.
You’re using global variables.

The difference is that an SC global variable [VAR_NAME] set as session in the SC IDE, at runtime is converted to:

$_SESSION[‘VAR_NAME’]

while an SC attribute {ATTR_NAME}, running in an app named APP_NAME, at runtime is converted to:

$_SESSION[‘APP_NAME’][‘ATTR_NAME’]

The attribute is still a session variable, but with APP_NAME scope: the goal is to have different apps running at the same time with the same attributes names and still be sure that they won’t overwrite each other.
Although if you use the standard full php standard syntax ($_SESSION[‘APP_NAME’][‘ATTR_NAME’]) in your code, off course you can access it and overwrite it from everywhere.

We are using the same approach of defining a single “item” in SC and then use it to store multiple values (you as an object, me as an array) but in your case you’re using it as an SC global var

[Kleyber_Derick]

Yes, my case is that I need to have a variable that can be accessed for all my apps… maybe it is the difference of your approach. So I just showed another way to do this, because I had many troubles with SC’s global variables and in my approach I don’t have the problems you have in grids… but as I said in my first reply, your approach is very good. I just disagree about my case is a global var… in my point of view it is a session var.

[robydago]

@Kleyber_Derick

I just disagree about my case is a global var… in my point of view it is a session var.

I was referring to the SC definition of it as a global var: you literally included in your post the screenshot from Application → Global Variable.

Off course in standard PHP they are just session vars, as I’ve shown in the converted code as $_SESSION[…].
SC Attributes are also session variables, but with an added ‘dimension’: $_SESSION[‘APP_NAME’][…].

[Kleyber_Derick]

@robydago

I was referring to the SC definition of it as a global var: you literally included in your post the screenshot from Application → Global Variable.

Ah ok, I understood your point.

[alvagar]

Here, an old POST about your question… i think SC TEAM Must solve us this question.

Multiple instances of the same app

Is it possible to run multiple instances of the same app in the same browser with the guarantee that all data context are kept separate and not shared ? For instance I have an app managing purchase orders . I need two purchase orders apps open on the screen at the same time. Global variables of course cannot be used becaused are shared between apps , but I suspect that even if I dont use globals the context of the two apps are still not managed separately.

[aducom]

That is not so easy. Session cookies are kept on the client, and if you open a new tab, then the server will request for the same session cookie (by name). I think it could work in private mode, though. But as long as sessions depend on session cookies…

[robydago]

@alvagar

Here, an old POST about your question… i think SC TEAM Must solve us this question.
Multiple instances of the same app

That’s a different topic.

In this topic I’m only talking about how to isolate variables sharing the same variables names among different apps, i.e. apps with different names running at the same time.

[aducom]

Sorry, I misunderstood then.