Centralized client logic:

Most ui components allow users to run custom logic on certain events. (ex. on initialize, on value change, on before save, ...)
These customizable events are available directly from the repository, as attributes.
The attributes support simple JavaScript syntax:

EventAttribute: '$ app.domain.function(eventSource);'

The attributes require the value to start with '$', denoting that the used syntax will be JavaScript. (at the moment only JavaScript is supported)

Most of the time, the events will require access to the context of the event. (the object that is triggering the event, the screen, ...)
For that we introduced the following reserved keywords:

• self (deprecated) - the underlying dynObj of the triggering object
• oSelf (deprecated) - the underlying controller of the triggering object
• eventSource - the object on which the event is triggered
• eventOrigin - the container from where the current screen was launched

The code implementation for centralized client logic is covered here: How to write centralized events

Decentralized client logic: (SWAT 22.13.0+)

As of SWAT 22.13.0, support for decentralized client logic has been introduced.
As seen in the example above, the functions need to be available in the global context to be able to reference them.
This means having to maintain that global context to avoid conflicts and having to reference the events by their full path.
Moreover, this also means that all the client logic is loaded in the main bundle.

With the decentralized client logic, the goal was to address all the issues mentioned above to improve performance and allow users to focus on the client logic itself and not its infrastructure.
With this approach, users are able to specify and reference custom client logic without including it in the global context and without preloading it. (it will  be lazy loaded on screen launch)

A new attribute 'EventNamespace' has been introduced for all repository objects.
When the attribute is assigned a namespace (ex. 'app.domain'), on screen launch, the corresponding file will be lazy loaded and injected into the specified namespace.
With this approach, the events will be specified exactly as above, there is no change in how the events are referenced, the main change is in how the logic is lazy loaded when required.
This means that the initial example from above remains as it is:

EventNamespace: 'app.domain'
EventAttribute: '$ app.domain.function(eventSource);'

This approach still requires users to specify the correct namespace in the events themselves.
We have simplified this with the introduction of a new reserved word 'eventNamespace', which will automatically map to the corresponding namespace:

EventNamespace: 'app.domain'
EventAttribute: '$ eventNamespace.function(eventSource);'

The last mentioned issue with the centralized logic was the polluted global scope.
To keep the global context clean, the '#' reserved namespace was introduced.
By using it, the namespace is loaded into the object at runtime, but is never exposed outside of it:

EventNamespace: '#'
EventAttribute: '$ #.function(eventSource);'

The code implementation for decentralized client logic is covered here: How to write decentralized events

To maintain backwards compatibility with the centralized client logic and to avoid redundant import checks, the decentralized client logic handling is activated only when an event namespace is assigned to the object master.
The event namespace needs to be assigned at object master level and, afterwards, it can be referenced within the master itself. (master-level, instance-level, menu-level).