To improve the runtime performance of a SWAT Framework-based application, the repository cache has been implemented to store the computed definition for all screens.
Once activated, performance is increased as the backend doesn't need to recompute the screen definitions, which can be a complex process.
Activation
Despite the improved performance, repository caching is disabled, by default, as it can interfere with the development process.
As implied, once a screen definition has been cached, it won't take into account any additional changes done to the screen itself until the cached version is removed.
To activate it, one simply needs to add the caching service to the application's services XML file:
<ttServiceLoaderRow>
<Order>10</Order>
<ServiceTypeName>Akioma.Swat.Repository.Cache.IRepositoryCacheService</ServiceTypeName>
<ServiceClassName>Akioma.Swat.Repository.Cache.DatabaseRepositoryCacheService</ServiceClassName>
</ttServiceLoaderRow>
Configuration
The database repository cache service supports the following PASOE config XML entries:
| Property name | Details |
|---|---|
| RepositoryCacheSkipList | A comma-separated list of screen name patterns, which is used to exclude them from the cache so they are recalculated each time they are requested by the user. |
Customization
As seen in the 'Activation' section, the repository cache functionality has been implemented through a SmartComponent Library service (Akioma.Swat.Repository.Cache.DatabaseRepositoryCacheService).
This means that the service implements an interface (Akioma.Swat.Repository.Cache.IRepositoryCacheService) and all interactions with the service are done through the interface.
The SWAT Framework support only one repository cache service, DatabaseRepositoryCacheService, which stores the definition in the database.
The repository service fully supports custom implementations of the IRepositoryCacheService interface.
Interaction with dynamic screens
The base builder class now has a new property: 'DynamicDefinition'.
By default, the property is false, in which case any screen containing the corresponding control is unaffected.
Whenever a screen contains a control which has the dynamic definition property set to true, it will be automatically excluded from the build.
This has been introduced for custom controls, where the definition changes during runtime.
As such, it is up to the developer of the custom control to decide whether it is dynamic at runtime or only at design-time.