
~~Title: Application Events for Real-Time AI~~

<html><font color=#990000 size="+2"><b>Application Events for Real-Time AI</b></font></html>

<color #00a2e8>Knowledge Works™</color> components support the same //Event// processing capabilities as the back-end data fabric platform. Users can create interactive, data-driven applications powered by StreamScape's Event Faric and Cognitive Analyics AI services. //Components// and //controls// in an application can communicate with each other via //events//. The environment allows users to //raise events//, //define triggers// and create //event consumers// that can process changes in component and control data. This makes it easy to develop desktop-style applications that offer an interactive,  well-coordinated and conversational user experience.  

For example, a medical application that allows users to view pandemic informatoin by state, may need to filter information displayed by all of its visual components for a specific state like New York.  A drop-down list box may allow the user to selecta state, which should trigger all other components in the application to immediatley apply the state //context filter// and chose only New York data to display. To accomplish this, the selection action should raise an event that is then //seen// by all relevant components. These components will consume the change event and each one will perfoem some logic that will chnage what is being displayed, thereby creating an interactive user experience.  

Applications can also react to events coming from other users or the back-end system, without any user interaction, allowing for avanced real-time, collaboartive applications to be developed.

\\

==== Application vs. Component Events ====

Controls, such as //Buttons//, //Text Boxes//, //Icons//, //Combo Boxes//, //Panels// and similar elements can raise events when their state changes as result of data fetch or user interactions. A //click// or //double click// operation can raise an event that other components of controls may need to process.  When combined with //IO Controls// and //Overlay Panels// and //Canvas Controls// events can play a critical role in creating a rich user experience, allowing the application's visual elements to change based on context.  This approach is very similar to how desk top application enviroments like Visual Basic, Adobe, Java SWING and legacy tools such as Powerbuilder handle visual component interactions.  Users with expeience in such tools will be able to re-use those skills to devlop real-time AI powered applications. To do so you only need to understand a few basic event processing primitives.

\\

=== Raise Event ===

Allow users to create and send //Data Events// which are application messages with some data content that can be processed by //Event Consumers//.  In the //Real-Time Application// framework, event consumers can be implicit (Event Triggers) or they may be directy defines as //Event Consumers//.  Implicit events are managed by the RTAI system.  Users can simply implement business logic in response to some action like //click// or //mouseover// or //data change//.  Implicit events are only //visible// to a component's trigger mechanisms.  Users do not need to know or understand the concepts of event structure or ''eventId'' that are created by internal actions.

Explicit events can be defined by users, along with event payload and sent using a ''raiseEvent(.)'' method, on a specific ''eventId''.  Raising an event makes it visible to any component that can define an //Event Consumer//.  This allows users to develop advanced components and applications that are dependent on each other's actions.  For example, canging a selected row in a grid of one component can trigger the change of map coordinates in another. 

\\

=== Event Trigger ===

Event triggers are defined on some entity that 

\\

=== Working with Events ===

Sending and receiving events is the core mechanism of RTAI applications.  //Components// and //Applications// are considered to have //segregated event scope//.  Meaning that by default components only see thier own events and can only react to local actions.  And applications can only see and react to events occuring at their level, inside application context.  However, raising events allows users to communicate with any component within the application.  This is done by defining //Triggers// or //Event Consumers//. 

==== Raising Events ====

  *  ''component.raiseEvent('<event id>', <event data>)'': raises an event to the //event dispatcher// that may be processed by a //Trigger// or //Consumer//

==== Component Event Triggers ====


  *  ''<color #7092be>component.addTrigger('<event id>', <function declaration></color>''  defines a trigger on an //event source// component, to process a component-local event 

==== Component Event Consumers ====

Component event consumers are intended for decoupled communications between controls or components within an application.  Unlike triggers, //Event Consumers// are able to process events raised by any application control or component, without explicit knowledge or access to the //event source//. 

  *  ''component.addConsumer('<event id>', <function declaration>)''  defines an event consumer on a component that wants to process a global event

  *  ''component.addConsumer('*', <function declaration>)''  defines a consumer on a component that can process all global events

  *  ''component.addConsumer(['<event A>','<event B>', ..], <function declaration>)''  defines a component event consumer on several global events

Note that the //SCOPE// of //Event Trigger// processing is //local//. Triggers can only see and process events that come from the component they are defined on.  This can be useful when developing complex, iteractive components that change context based on user input or data changes.  //Event Consumer// has a so-called //Global// scope. It can process events from anywhere inthe application and is typically declared on a component that is the cordinator, or on the //application component// itself. 

==== Application Event Consumers ====

Application event consumers are intended as a centralized coordination mechanism that allows for cooperative actions between application components.  Event consumers defined at the application level will //see// events raised explicitly by component actions by ''raiseEvent(.)'' logic.  Additionally, control actions have the ability to automatically raise events using default or user-defined ''eventId''.

  *  ''app.addConsumer('<event id>', <function declaration>)''  defines an event consumer on the application //container component//

  *  ''app.addConsumer('*', <function declaration>)''  defines an consumer on all events in an application // container component//

  *  ''app.addConsumer(['<event A>','<event B>', ..], <function declaration>)''  defines an application event consumer on several global events

This design is essential for separating event procesing logic from application components.  Since the //application event consumers// are not depenent on any application components, their event processing logic will be added to the application whenever the application initializes.  On the other hand, components in an applicaiton that cannot initialize properly will not add their event processing logic to the application. Components that failed to initialize will be marked //missing// and a visual exception will be shown to the user.

\\

=== Example of Working With Events ===

IN the example below, an implicit //Trigger// on a //Button// control is raising ane event wth a simple data payload.  Payloads can be defined as any arbitrary, valid JSON structure.  Improperly formed JSON strings will still e processed byt he event framework but may cause exceptions is they are
'coerced' back into Object form.

<sxh DSQL; gutter: true;>

  //button trigger in component
  function(event, control, component, anchor, data) { 
    component.raiseEvent('ClickRelayedFromTrigger', {someData:123});
  }

  //in dashboard script:
  myComponent.addTrigger('ClickRelayedFromTrigger',function(event, data){ 
    console.log(event,data);
  });
 
</sxh>


\\