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.
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.