Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Section
Column
width60%

The Infusion framework defines a event system which is used by many of its components.

Why did we construct a new event system when there are (at least) two event systems already in common use in a jQuery-enabled page? Browser events and their jQuerified equivalents are too tied to the DOM and its infrastructure. Considered in MVC terms, a jQuery event is more appropriately attached to the View layer of an application, whereas Fluid events are used to propagate pure Javascript function calls, and more appropriately attached to the Model layer. Using browser/jQuery events in this context would lead to inappropriate responsibilities for having to always determine a DOM node as the target/originator for an event, and to have a constrained event signature which must accept a browser event as the first argument.

Anchor
nameeventtypesdescription

Events Types

By default, most Fluid component events are multi-cast (that is the event is fired to all registered listeners), but some events may be one of the following two special types:

Include Page
Infusion13:Event Types
Infusion13:Event Types
Include Page
Infusion13:Event FirersInfusion13:Event Firers

Events and options merging

In order to make it as easy as possible for Fluid component authors to define their event types and accept and manage listeners, Fluid event firers have a special status during the Fluid options merging process.

Column
Panel
borderColor#566b30
bgColor#fff
titleBGColor#D3E3C4
titleOn This Page
borderStylesolid
Table of Contents
minLevel2
maxLevel5
Panel
borderColor#321137
bgColor#fff
titleBGColor#c1b7c3
titleSee Also
borderStylesolid
Panel
borderColor#321137
bgColor#fff
titleBGColor#cccccc
titleStill need help?
borderStylesolid

Join the infusion-users mailing list and ask your questions there.

Include Page
Infusion13:Event Firers
Infusion13:Event Firers

Events and options merging

In order to make it as easy as possible for Fluid component authors to define their event types and accept and manage listeners, Fluid event firers have a special status during the Fluid options merging process.

events in options

A component may declare as part of its options structure a top-level structure named events whose keys correspond to event types that this component wishes to support, and whose values are either null or the string values "unicast" or "preventable" corresponding to the accepted arguments for getEventFirer. As part of the normal construction process of fluid.initView(), the top-level that object for the component will automatically have constructed a corresponding event firer object for each one of these events.

...