Who wants real CONSTANTS?

By Tiago Bernardo on 21 Jul 2010
Not Static Entities, not Site Properties, real constants!

For now I use actions, which are functions, like CONST___*, which return a constant value.
Nuno Fernandes21 Jul 2010
I don't like using literals in the code so I prefer using Site properties... but then again: then are site properties meant to be configurable and other meant to be constants...
Tiago Bernardo21 Jul 2010
When you change Site Properties (add, delete, change default value) you are forced to Publish before you can debug...
Nuno Fernandes21 Jul 2010
Wouldn't you need to publish also using constants?
Tiago Bernardo21 Jul 2010
To start a debug session I suppose no.
When I create/change/delete a new user action, to start a debug session, it's no necessary to publish the espace.
With Constants I suppose it would be the same.
J.22 Jul 2010

what's the advantage then over actions?

Goncalo Borrega22 Jul 2010
I rather use Static Entities. They can work just like enumerables or constants and the Id value is stored/cached in memory so it never needs to go to the database if you  just use it like a const.
On top of that the platform already provides you with intellisense and strong-type (showing you the possible values if you declare the variable as that type) so I think it really covers much more the constants
Nuno Fernandes22 Jul 2010
Fully agree with Gonçalo.
Tiago Bernardo22 Jul 2010
"what's the advantage then over actions?"

It would be a would a well defined "concept", not an action disguised as a constant.


Tiago Bernardo22 Jul 2010
Consider this cenario:

Use the built-in action Audit but use well defined literals to use as values for the parameter "ModuleName", so there won't be simillar values over the espace used in Audit actions like: "module_name_1", "modulename1", modulenameone", "ModuleName1", etc.

What solution would you use?

We could use a Static Entity "AUDIT_MODULE_NAME" with some records, for instance MODULE_NAME_1 with attributes Id and Value, and use "ModuleNameOne" for the value.
To use this in the ModuleName parameter you would have to write:

GetAUDIT_MODULE_NAME (Entities.AUDIT_MODULE_NAME.MODULE_NAME_1).AUDIT_MODULE_NAME.Value

Is this the best solution for this?
Goncalo Borrega22 Jul 2010
I would just use a static entity that instead of an integer key has a Code (Text) key...

When you use Entities.MODULE_NAME.ModuleABC the platform will return you the Code (which in your case would be a text with ModuleNameOne)
Tiago Bernardo22 Jul 2010
Thank you! I got it now.
Tiago Bernardo23 Jul 2010
I've tried to use Static Entities as Constants the way you described but it has not been a natural process and I've encountered some difficulties...

Created Static Entity ENUM_Module, with only one attribute Value, text, which is defined as primary key. Added the records, Module_One, Module_Two.
I can use references like "Entities.ENUM_Module.Module_One". Good.
I wanted to document what each Module in each record should be used for. I couldn't. Added attribute "Description". Ok.
Published.
Now I want to change the value of the _constant_ Module_One from "a_module" to "the_module". I can't:
"The primary key value of a record cannot be changed."

I guess I must be doing something wrong...
Goncalo Borrega23 Jul 2010
Remove the current one and add a new one with the same Identifier (the attribute ServiceStudio uses for Intellisense/using in the code) but a different key attribute value...?
Igor Kirtak5 Jun 2015
Just wanted to create the same idea, but found this one.
Yes, we have static entities and site properties, but both have disadvantages.

Static entities:
- Are stored in DB as tables. I would prefer to avoid extra tables just to store constant values
- Reading them from DB is additional unneeded overhead
- Their values can be edited or deleted by somebody who has DB access, it can be done accidentally, and can go unnoticed for some time
- They take system objects (limited by license), so that I often consider whether should I use another static entity or just hardcode values instead
- Static entities are like enums, having a need to constant one single value - what do you do? Add entity to hold single value? Create generic "Constant" entity? Especially knowing that this will create additional DB table

Site properties:
- You can't group them (sometimes you still need something like enum, which static entities provide, but site properties don't)
- They can be edited in administration, moreover, the abillity to edit them is their core feature, while the idea of the constant is that it is never changed
- Technical internal constants create garbage in the administration, there is no need for your constants to be seen outside

Possible solution is something like "no-DB static entities", which would be similar to static entities, but will not be stored in DB and will contain just Name and Value (of some basic type to be selected).
Igor Kirtak5 Jun 2015
One more thing to add to disadvantages of site properties:
- They are not strongly typed, so you can't make an action require specific set of constants, like you would do with static entities. Off course, if making some analogue of simple constants (e.g. const int Abc = 1) - this will have the same disadvantage, so analogue of enums (like "no-DB static entities") would be better.
J.5 Jun 2015
Static entities:
- Are stored in DB as tables. I would prefer to avoid extra tables just to store constant values

that's a preference, not a disadvantage.
the advantage is, all data is in the same place, you can query more easily etc.


- Reading them from DB is additional unneeded overhead
it's cached, so not that many unneeded overhead

- Their values can be edited or deleted by somebody who has DB access, it can be done accidentally, and can go unnoticed for some time


Erm, that can be done with "normal" constants as well.
And if people do tend to "screw" up statics in the database, I wonder why they have access in the first place.
It's not really needed to dig into the outsystems-database...

- They take system objects (limited by license), so that I often consider whether should I use another static entity or just hardcode values instead
True, but that goes for everything.


- Static entities are like enums, having a need to constant one single value - what do you do? Add entity to hold single value? Create generic "Constant" entity? Especially knowing that this will create additional DB table


one single value you should use site-properties...


Site properties:
- You can't group them (sometimes you still need something like enum, which static entities provide, but site properties don't)

well, site properties are not supposed to do that...


- They can be edited in administration, moreover, the abillity to edit them is their core feature, while the idea of the constant is that it is never changed

so make it an action then?

- Technical internal constants create garbage in the administration, there is no need for your constants to be seen outside


so make it an action then?


I don't see really an advantage to add "CONSTANTS" instead of site-properties and/or static-entities and/or actions.
It just makes it less maintainable imho and dropping us back into 3GL again.