Behaviors - Revision history

Luc Morissette at 17:47, 25 August 2020

2020-08-25T17:47:32Z

Song tao xie at 17:04, 5 August 2020

2020-08-05T17:04:30Z

Abrassard: /* Caveats */

2010-09-13T11:58:07Z

Caveats

Ktrueman: clean up

2009-07-23T20:54:14Z

clean up

Ktrueman: /* Usage */ clean up

2009-07-23T20:53:01Z

Usage: clean up

Ktrueman: some clean up and new links

2009-07-06T18:42:55Z

some clean up and new links

Ktrueman: /* Usage */

2009-05-08T14:09:49Z

Usage

Ktrueman: /* Usage */

2009-05-08T13:55:51Z

Usage

Ktrueman: /* Usage */

2009-05-08T13:52:32Z

Usage

Ktrueman: /* Usage */

2009-05-08T13:52:16Z

Usage

@@ Line 2: / Line 2: @@
 Here are examples of features that make good behaviors:
-*[[Sip_headers_manipulation]]
+*[[Sip headers manipulation]]
 *[[Ringback tones]]
 *Voicemail fallback

@@ Line 2: / Line 2: @@
 Here are examples of features that make good behaviors:
 *[[Ringback tones]]
 *Voicemail fallback

← Older revision		Revision as of 11:58, 13 September 2010
Line 33:		Line 33:

	== Caveats ==		== Caveats ==
−	Behaviors should be careful with the state of the call since the may be used on any type of call. For example a check should be made to be ~~shure~~ a leg exists before using it. This should prevent crashes in case of invalid usage of the behavior.	+	Behaviors should be careful with the state of the call since the may be used on any type of call. For example a check should be made to be sure a leg exists before using it. This should prevent crashes in case of invalid usage of the behavior.

← Older revision		Revision as of 20:54, 23 July 2009
Line 1:		Line 1:
−	Services must usually contain a variable number of features. Coding all these features in the ~~[[TBCAF::ITBCAFCallClassReference\|~~ITBCAFCall]]subclasses might become hard to maintain has the number of features increase. Behaviors provide a way to implement these features in separate classes which are attached to a call at runtime. Basically a behavior traps all events for a call’s legs so it can act on the events and optionally forward them to the rest of the behavior chain. This chain is constructed at the initialization of the call as seen in the next section so that every call can have a different chain (therefore different features).	+	Services must usually contain a variable number of features. Coding all these features in the ITBCAFCall subclasses might become hard to maintain has the number of features increase. Behaviors provide a way to implement these features in separate classes which are attached to a call at runtime. Basically a behavior traps all events for a call’s legs so it can act on the events and optionally forward them to the rest of the behavior chain. This chain is constructed at the initialization of the call as seen in the next section so that every call can have a different chain (therefore different features).

	Here are examples of features that make good behaviors:		Here are examples of features that make good behaviors:

@@ Line 22: / Line 22: @@
 == Usage ==
-Behaviors must be subclasses of [[CallBehaviors|CTBCAFCallBehavior]] which delegates all events to it’s parent by default. The new behavior must implement the event handlers only for the events it needs and must decide whether or not to delegate the event (capturing the event or letting others use it). The [[TBCAF::CTBCAFCallBehaviorRbt|CTBCAFCallBehaviorRbt]], [[TBCAF::CTBCAFCallBehaviorVoiceMail|CTBCAFCallBehaviorVoiceMail]], [[TBCAF::CTBCAFCallBehaviorFollowMe|CTBCAFCallBehaviorFollowMe]], [[TBCAF::CTBCAFCallBehaviorFaxRelay|CTBCAFCallBehaviorFaxRelay]] classes are good examples of various kinds of simple behaviors.
+Behaviors must be subclasses of CTBCAFCallBehavior which delegates all events to it’s parent by default. The new behavior must implement the event handlers only for the events it needs and must decide whether or not to delegate the event (capturing the event or letting others use it). The CTBCAFCallBehaviorRbt, CTBCAFCallBehaviorVoiceMail, CTBCAFCallBehaviorFollowMe, CTBCAFCallBehaviorFaxRelay classes are good examples of various kinds of simple behaviors.
 The following code demonstrates how to decorate a call with ringback tone and voicemail fallback behaviors:

@@ Line 1: / Line 1: @@
-Services must usually contain a variable number of features. Coding all these features in the ITBCAFCall subclasses might become hard to maintain has the number of features increase. Behaviors provide a way to implement these features in separate classes which are attached to a call at runtime. Basically a behavior traps all events for a call’s legs so it can act on the events and optionally forward them to the rest of the behavior chain. This chain is constructed at the initialization of the call as seen in the next section so that every call can have a different chain (therefore different features).
+Services must usually contain a variable number of features. Coding all these features in the [[TBCAF::ITBCAFCallClassReference|ITBCAFCall]]subclasses might become hard to maintain has the number of features increase. Behaviors provide a way to implement these features in separate classes which are attached to a call at runtime. Basically a behavior traps all events for a call’s legs so it can act on the events and optionally forward them to the rest of the behavior chain. This chain is constructed at the initialization of the call as seen in the next section so that every call can have a different chain (therefore different features).
 Here are examples of features that make good behaviors:
-*Ringback tones
+*[[Ringback tones]]
 *Voicemail fallback
 *Follow me
-*Call detail record
+*[[call detail record|Call detail record]]
-*Fax relay (over VOIP)
+*[[Fax over IP]] (fax relay)
-*Your bright ideas...
+*Your 'bright ideas'...
-The decorator pattern is used by behaviors to provide this level of flexibility; behaviors decorate the default [[TBCAF::ITBCAFCallClassReference|ITBCAFCall]] subclasses doings. A specific behavior can be used on any ITBCAFCall subclasses, as long as they are compatible in their doings e.g. Using a generic "Follow Me" behavior might not work as intended on a prepaid call).
+The decorator pattern is used by behaviors to provide this level of flexibility; behaviors decorate the default ITBCAFCall subclasses doings. A specific behavior can be used on any ITBCAFCall subclasses, as long as they are compatible in their doings e.g. Using a generic "Follow Me" behavior might not work as intended on a prepaid call).
-Additionally, protocol specific behaviors can be created to remove any protocol aware code in the base classes. These behaviors can then be dynamically added to the calls depending on their protocol.
+Additionally, protocol-specific behaviors can be created to remove any protocol-aware code in the base classes. These behaviors can then be dynamically added to calls depending on their protocol.
-Behaviors could be implemented through simple inheritance but it is less flexible. Indeed, a class for each combination of features would be required; so the classes needed for the example below would be:
+Behaviors could be implemented through simple inheritance but this approach is somewhat less flexible. Indeed, a class for each combination of features would be required; so the classes needed for the example below would be:
 *CMyCall
 *CMyCallRingbackTone
@@ Line 34: / Line 34: @@
 == Caveats ==
 Behaviors should be careful with the state of the call since the may be used on any type of call. For example a check should be made to be shure a leg exists before using it. This should prevent crashes in case of invalid usage of the behavior.