The automatic refresh mechanism works by notifying all Business Entities that match the currently updated Business Entity table or custom handling using the RefreshScheme Attribute settings.
If the update/delete/create operations are not done using the Business Entity from the repository then the correct way to handle the refresh is by ClientLogic code, triggering the refresh programmatically for the needed entity tables.
The auto refresh is handled based on refresh schemes.
| Code Block | ||||
|---|---|---|---|---|
| ||||
// working with one table
{
"Tables": "Table1*", // table name or comma separated list of multiple tables names
"AddRepositionTo": '#NewRecord', // default reposition to newly created record (other options: #KeepSelection, #NextRow)
"UpdateRepositionTo":'#KeepSelection', // default keeps selection of the selected record (other options: #NextRow)
"RemoveRepositionTo": '#NextRow' // default reposition to next available record using #NextRow
}
??
// working with multiple tables
// In addition to just setting one option for the RepositionTo handling, you are able to setup multiple options per Table listener
// Recommendation: if you define multiple tables, it's best practice to define the RepositionTo handle for all of them
{
"Tables": "eFeMeldungTable1*, eTerminTable2*",
"AddRepositionTo": "#NewRecord,#KeepSelection", //default reposition to newly created record
"UpdateRepositionTo":"#KeepSelection,#KeepSelection", // default keeps selection of the selected record
"RemoveRepositionTo": "#NextRow,#KeepSelection" // default reposition to next available record using #NextRow
} |
Above is the default Scheme, the refresh will add the BEs Business Entites own entityTable by default and you can add multiple Tables in the refreshScheme.Tables.
...
| Info |
|---|
Wildcard support is available, as you can see in the above examples where using 'eTerm*' For the moment, only 'begins with' is supported in the wildcard. |
| Info | ||
|---|---|---|
| ||
The refresh scheme is not used to mention on which tables to refresh the data, actually the tables present in refresh schemes represent a list of listeners for the changes that will occur in the mentioned tables, which means that if an update / add / delete is done on one of the tables specified in the refresh schemes then the refresh will be done on the DSO table, not the other way around. |
Starting with the SWAT 2019.23 release, also SkipRefresh parameters are available.
- AddSkipRefresh
- UpdateSkipRefresh
- RemoveSkipRefresh
These params are a comma separated list of table names which will be ignored/skipped upon refresh. Wildcards still work for the skipRefresh lists. If the developer want's to skip all, he/she can add * (star/asterisk).
| Code Block | ||||
|---|---|---|---|---|
| ||||
{
"Tables": "Table1*,Table2*",
"AddRepositionTo": "#NewRecord,#KeepSelection", //default reposition to newly created record
"UpdateRepositionTo":"#KeepSelection,#KeepSelection", // default keeps selection of the selected record
"RemoveRepositionTo": "#NextRow,#KeepSelection" // default reposition to next available record using #NextRow
"AddSkipRefresh": "*", // all tables are skipped for refresh on add action
"UpdateSkipRefresh": "Table2" // Table2 will not be refreshed on update action
} |
Starting with SWAT 2020.01 release, also the RepositionToKey parameter was added, to specify what field to use from the BE for the reposition (eg: what record from a grid)
| Code Block | ||
|---|---|---|
| ||
{
'Tables': 'Table1*,Table2*',
'AddRepositionTo': '#NewRecord,#KeepSelection',
'UpdateRepositionTo':'#KeepSelection,#KeepSelection',
'RemoveRepositionTo': '#NextRow,#KeepSelection' ,
'RepositionToKey' : 'selfhdl,user_key'
} |
Starting with 2020.13, a new parameter refreshConditionCallback is available, support for callback refreshScheme method:
| Code Block | ||
|---|---|---|
| ||
{
"Tables" : "Table1,Table2",
"UpdateSkipRefresh": "Table2",
"RefreshConditionCallback":"akioma.Function_Name(eventSource)"
} |