ERP 2.50:Developers Guide/Concepts/AD/Dynamic Expressions
Contents |
Introduction
Dynamic Expressions are used to obtain values that can depend on session values. For example they can be used to to filter the records that appear in a tab by the ones that were created by the user that has logged into the application.
Session values
Depending on how they are defined, there are different kinds of session values.
It is possible to check (as System Administrator) all current values loaded in session in General Setup || Application || Session Variables window.
Types
Session global variables
These values are generated by Java classes and are accessible from anywhere in the application.
Columns
Values for all columns used in a tab are accessible as session variables within that tab.
Additionally it is also possible to set explicitly a column a session value by setting its Stored in Session attribute. This will make this value accessible not only for its tab but also for all the tabs in that window.
Preferences
Preferences allow to define session values. It is possible to define preferences for a single window or for all of them (leaving blank the window field) and for one user or for all of them. Preferences are defined in General Setup || Application || Preference window.
When the attribute value matches with a column name. it will be used as default value for that column overwriting the standard default value for that column.
Preferences can be defined for a window and user. If the window is empty, the preference applies globally to the whole application, if not, only to the selected window. In a similar way, in case the user is blank, the preference will be shared among all users, other case the preference will be applied just to the selected user.
 | All the following sections related to preferences are available from 2.50MP18. |
For a list of current system preferences see this wiki page.
Definition
There are two ways of defining a preference, it can be switched by using the Property List check field:
- Property. (Property List checked). The preference can be taken from a fixed list. It is a list reference named Property Configuration. Modules can add new items to this list with the purpose that other modules can set values to them.
- Attribute. (Property List unchecked). The preference is defined by the Attribute field, which is a free text input box.
Visibility
Preference visibility defines in which cases the preference will be used. It can be defined at different levels. All of them can be set or leave blank, in case a visibility level is empty, it is not applied so it is visible from any value of that level; for example if user is empty, any user will be able to see that preference. In case the same preference has values at different levels, it will be used the most specific one. The levels are the following:
- Client. Defines the client, if it is empty or System the preference will be visible from any client.
- Organization. Defines the visibility from the organization that has been logged in the session. Note that the organization is not the document organization but the one used during the login. So if a role has access to organization A and B, both organization has a value for the same preference and the user logs in the application with that role and organization A, the value defined for that organization will be used, even when creating a document (for example an invoice) in organization B. If it is empty or * it will be visible from all the organizations. Visibility for organizations is calculated taking into account organization tree; this is, if the organization tree looks like A with a child organization A1, preferences defined for A will be visible from A and A1 in case A1 has not a value for them.
- User and Role. Which is the user/role that will be able to use the preference.
- Window. From which window the preference will be visible.
Getting/setting preference values
When logging in the application or changing role, preferences visible for that user/role/client/org are stored in session, that values can be obtained using the org.openbravo.erpCommon.utility.Utility.getContext method.
Additionally, it is possible to look for the value of a preference querying to database using the org.openbravo.erpCommon.businessUtility.Preferences.getPreferenceValue method. This method throws an exception in case the property has not a value defined visible from the current visibility level (passed as parameters), it also raises an exception in case of conflict (more than one value defined for the property at the current visibility level).
Preferences can be set programatically through org.openbravo.erpCommon.businessUtility.Preferences.setPreferenceValue method.
Conflicts
A conflict for a preference occurs in case the same preference is defined with different values at the same visibility level. When this happens, one of them will be stored in session when login in the application or changing the role. If the preference value is tried to be obtained using org.openbravo.erpCommon.businessUtility.Preferences.getPreferenceValue method, a PropertyConflictException will be thrown.
Conflicts can be manually resolved by user, checking the selected field of the preference. In this case the selected value preference will prevail over the rest.
Modularity
Preferences can be optionally assigned to a module. In this case they will be exported as part of the module. This makes sense in case it is wanted to define in a module general settings that will be reused.
Auxiliary inputs
Auxiliary Inputs are used to create a session value for a concrete tab. This value can be calculated using a Dynamic Expression and it purpose is to use it in other Dynamic expressions within the tab it is defined for.
Auxiliary inputs are computed when a record is selected in the grid. This means that they cannot be used in the where clauses of header tabs, because when a header tab is loaded for the first time, no records are selected yet. Even if the header tab is refreshed after selecting a record the auxiliary input could not be used, as the context info of selected record is not sent when its grid is refreshed.
Auxiliary Inputs are defined in Application Dictionary || Setup || Auxiliary Input tab.
Accessibility
It is possible that there are different session values types with the same name that are accessible at the same point, in this case (unless it is explicitly specified to take the value in a global session value) the value will be taken following the next approach:
- Try to get a preference with the specified name for the current window.
- If no value has been obtained, try to get a value associated to the current window
- If no value has been obtained, look for a global session value.
Syntax and types in Dynamic Expressions
Using session values
In Dynamic expressions session values are obtained by their name surrounded by at symbols (@). Thus to get the content of a session value called myValue, it would be done typing @myValue@. Doing it in this manner it would follow the accessibility described above, but it is possible to explicitly obtain the global value (if exists) not taken into account the other ones, to do so the value would have a sharp symbol (#) as prefix. In the previous example it would be @#myValue@.
Dynamic expressions types
There are different types for Dynamic Expression, each type can be used depending on the Application Dictionary object it is defined in. A complete list of all the objects and which kind of expression can use is defined in the next section.
The types are:
Constant
It can a constant value or a value in stored in session, this type can be used by all the objects. To set this type no prefix is needed.
Examples:
1
@#AD_User_ID@
SQL
Some objects accept SQL expressions. This type must have a @SQL= prefix followed by the SQL clause. It also accepts session values.
Example:
@SQL=SELECT DOCSUBTYPESO
FROM C_DOCTYPE
WHERE C_DOCTYPE_ID = @C_DOCTYPETARGET_ID@
WhereClause
It is a SQL where clause, in this case it is not necessary to add the @SQL= prefix.
Checks
It is used to obtain a boolean value. It does not have any prefix.
Its syntax is Javascript but the comparators are:
- = instead of ==
- ! instead of !=
- & instead of &&
- | instead of ||
Dynamic Expressions used in Application Dictionary objects
| AD Column | Type |
| AD_AlertRule.FilterClause | WhereClause |
| AD_AuxiliarInput.Code | SQL |
| AD_Column.ReadOnlyLogic | Check |
| AD_Dataset_Table.WhereClause | WhereClause |
| AD_Field.DisplayLogic | Check |
| AD_Ref_Table.OrderByClause | WhereClause (order by clause) |
| AD_Ref_Table.WhereClause | WhereClause |
| AD_Tab.FilterClause | WhereClause |
| AD_Tab.OrderByClause | WhereClause (order by clause) |
| AD_Tab.WhereClause | WhereClause |
| AD_Val_Rule.Code | SQL |
| Languages: |
ERP 2.50:Developers Guide/Concepts/AD/Commons | ERP 2.50:Developers Guide/Concepts/AD/Element and Synchronize Terminology