Events

Simple v. Complex Events

Most events in SA5 Events are defined by attributes directly on the affected element. However, there is a potential for "attribute glut" and complexity here in two situations;

• If a single element has many possible Events triggering many possible Actions.

  • e.g. A tabstrip where 10 buttons might activate 10 different tabstrip actions.

• If an Event fires many different Actions on many different elements to a point where it's easy to lose track of the attributes in use.

  • e.g. A button Trigger, whose Action triggers 100 different Events.

In both cases, we can potentially centralize the admin with an Event configuration block.

This would look something like;

<script type="sa5-event+json" name="event1">
{
  "actions": [
    {
      "type": "scrollToPercent",
      "value": "50%"
    },
    {
      "type": "selectTabNum",
      "target": "tab1",
      "value": "2" 
    }
  ]
}
</script> 

There may be a case for supportin

Frequency Gating

Unlimited ( default )

Once

N-Times

Max frequency ( no more than once every 500ms )

Event

An SA5 Event is effectively a messaging pipeline, which has a name. When an event fires, it triggers a series of SA5 Actions.

• Multiple Triggers can invoke the same Event.

• An Event can perform several Actions

We're considering the ability for a single Trigger to invoke multiple Events. This may be limited to certain trigger types.

An SA5 Event is a named construction, which connects Triggers and Actions.

Events are tracked by SA5 and always have a name, so that they can be invoked and logged.

Element Click Trigger

wfu-trigger-click="event1"

wfu-action-click="event1"

Sa5.Events.Invoke("event1");

Currently, all events must be named.

Technical Notes & Consideration

Preventing Loops

Simple - threading. limit the number of automated events that can chain.

Event stack? Breadcrumbs? Detect loops?