XUL Programmer's Reference Manual

<broadcaster>

Attributes Common Children
id  * * *
action  
value  
oncommand  
   

 

<observes>

Attributes Common Children
id  * * *
element  
attribute  
mapto  
event  
   

Broadcasters and Observers are a mechanism for making any number of elements aware of state and event information from a single, "broadcasting" element. When an attribute on a broadcaster changes, the broadcaster broadcasts this state change to the interested observers--which indicate that they are interested by uniquely identifying the appropriate broadcaster (.e.g., <observes element="the id of the one I'm interested in" />).

This mechanism is useful for preserving the consistency of different UI elements (such as the Cut command in a context menu, the Cut toolbar button, and the Cut command from the Edit menu) when they perform the same tasks. The broadcaster/observer relationship is flexible and powerful. The following sections provide examples of different ways in which this relationship can be expressed in XUL.

Simple Observers

Broadcasters are typically invisible elements, though they don't need to be. Any element can be a broadcaster or observer, and the broadcaster/observer relationship can exist between any two elements. When an element that is not explicitly a broadcaster is broadcasting information, the observing elements observe by naming the broadcasting element with the element attribute. The following example shows this weakest sort of broadcaster/observer relationship, which is that between two regular elements:

<menuitem name="cut" />
 
<titledbutton value="Cut">
  <observes element="cut" attribute="disabled"/>
</titledbutton>
...

One-to-Many Broadcasting

Though this is a simple way to take advantage of broadcasting, it is inefficient because it puts a normal menuitem in a position of broadcasting to a button, which is one of its UI peers. A better mechanism is to define a separate broadcaster node to which all the visible UI elements pay attention. In this way, the state of the node can be maintained in a single place and tracked consistently.

<broadcaster id="cut"/>
 ...
<menuitem name="Cut">
 <observes element="cut" attribute="disabled"/>
</menuitem>
 ...
<titledbutton value="Cut">
 <observes element="cut" attribute="disabled"/>
</titledbutton>
 ... 

Command Nodes and the observes Attribute

In the preceding example, the menuitem and the titledbutton pick up the disabled attribute of the broadcaster node. The broadcaster node have any number of attributes that can be observed by other elements. When you want to broadcast all the attributes of a node, you can also use a slightly different construct. Compare the following example:

<command id="cutCommand" 
  oncommand="specialCut()" 
  value="Cut Me!"
  disabled="false" /> 

<menuitem observes="cutCommand"/> 
<titledbutton observes="cutCommand"/> 
<key observes="cutCommand"/>  
... 

In this construct, the broadcaster is a commmand node, whose responsibility it is to broadcast command functionality to all elements that observe it. Access to the specialCut() command is centralized in a single place. In a way, it's also protected by the disabled attribute, which controls whether any of the observing nodes can use the command and whether their own UI ought to reflect the availability of the command or not. A UI element observing the cutCommand broadcaster is automatically disabled because of the way that observers pick up the attributes of broadcasters in this second type of broadcaster/observer relationship. In all cases where the UI element includes a value attribute that specifies what's actually displayed, the broadcaster's value attribute is also used.

Other Observer Attributes

 


 

Last updated: 2/21/00 Ian Oeschger