Create the global variable Concept
1266
Views
5
Comments
On our RadarOn our Radar
Frontend (App Interfaces)
Sometimes there is the need to share the same variable across eSpaces.

EnterpriseManager had the global variables concept, but one would have to hardcode the name of the variable everywhere to get its value.

I've seen Static Entities used for this... (267 SUs for a producer eSpace with one static entity with one Id field and a name field, and a consumer with a user action)

I've see public actions with only one assign and one output text value for this...(24 SUs for both a producer and consumer eSpaces, where the consumer consumes the id in a user action)

I've also even seen Site properties used for this, with public actions to expose them...(but this one i would not advocate because site properties aren't the same as static variables)

Now, a good thing would really be a system static global variable concept at the action (dll) level or something like it.

This way you would have it centralized, wouldn't need to reach the DB for these, and wouldn't have to build an action to expose hardcoded values...and also, i believe we could reach a reasonable value with those SUs, less costy than static entities, but a little more than public actions exposing parameters...to justify its use.
I like it. I think site properties should be referenceable.
2016-04-21 20-09-55
J.
 
MVP
I don't like the idea.

You can kill multiple espaces in 1 go, because some muppet changed a global variable.
It's too much of an exposure imho.

That you can do today also, while using anything that's public.
Agreed. Similary, you could say "you can kill functionality spread across multiple eSpaces because some muppet forgot to change one of the 10 local variables".

I'd like to revive this idea and give it a priority.

Let's use the example of the Google Maps Forge item.

If I add multiple maps, they all come with the same overhead as follows:

If there was a way to set a Global Variable, you could set a flag to indicate that the google scripts was already served to the client.

I've noticed a lot of the JavaScript (by the OS Labs) is written in such a way that it fights with the idea that it might have run already.

DRY principle!

There is no need to turn a 30KB page into 2MB


It might feel tempting to suggest the following bad ideas: 

  • writing to the database per web request (performance and maintenance nightmare)
  • using session variables (they are shared between browser tabs)
  • site properties (they are shared universally over the whole application)