Behaviors - Revision history

Allyntree at 13:56, 20 July 2022

2022-07-20T13:56:34Z

← Older revision		Revision as of 09:56, 20 July 2022
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).		{{DISPLAYTITLE:Behaviors}}
			Services usually contain a variable number of features. Coding all these features in the ITBCAFCall subclasses may become hard to maintain as 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 10:		Line 11:
	*Your 'bright ideas'...		*Your 'bright ideas'...

	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).		The decorator pattern is used by behaviors to provide this level of flexibility; behaviors decorate the default ITBCAFCall subclasses. A specific behavior can be used on any ITBCAFCall subclasses, as long as they are compatible with the feature. For example, 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 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 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:		Behaviors can 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		*CMyCall
	*CMyCallRingbackTone		*CMyCallRingbackTone
	*CMyVoiceMailFallback		*CMyVoiceMailFallback
	*CMyCallRingbackToneVoiceMailFallback		*CMyCallRingbackToneVoiceMailFallback
	*CMyVoiceMailFallbackCallRingbackTone (~~makes no~~ sense in this case but it could make sense for some behaviors) Since the number of classes would be an ~~exponetial~~ of the number of features, we deemed this not acceptable and used decoration instead.		*CMyVoiceMailFallbackCallRingbackTone (This does not make sense in this case but it could make sense for some behaviors.) Since the number of classes would be an exponential of the number of features, we deemed this not acceptable and used decoration instead.


	== Usage ==		== Usage ==
	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.		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:		The following code demonstrates how to decorate a call with ringback tone and voicemail fallback behaviors:
Line 34:		Line 36:

	== 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 sure 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 they may be used on any type of call. For example, a check should be made to be sure a call leg exists before using it. This would prevent crashes in case of an invalid use of a behavior.

Luc Morissette at 17:47, 25 August 2020

2020-08-25T17:47:32Z

← Older revision		Revision as of 13:47, 25 August 2020
Line 2:		Line 2:

	Here are examples of features that make good behaviors:		Here are examples of features that make good behaviors:
	*[[~~Sip_headers_manipulation~~]]		*[[Sip headers manipulation]]
	*[[Ringback tones]]		*[[Ringback tones]]
	*Voicemail fallback		*Voicemail fallback

Song tao xie at 17:04, 5 August 2020

2020-08-05T17:04:30Z

← Older revision		Revision as of 13:04, 5 August 2020
Line 2:		Line 2:

	Here are examples of features that make good behaviors:		Here are examples of features that make good behaviors:
			*[[Sip_headers_manipulation]]
	*[[Ringback tones]]		*[[Ringback tones]]
	*Voicemail fallback		*Voicemail fallback

Abrassard: /* Caveats */

2010-09-13T11:58:07Z

Caveats

← Older revision		Revision as of 07: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.

Ktrueman: clean up

2009-07-23T20:54:14Z

clean up

← Older revision		Revision as of 16: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:

Ktrueman: /* Usage */ clean up

2009-07-23T20:53:01Z

Usage: clean up

← Older revision		Revision as of 16:53, 23 July 2009
Line 22:		Line 22:

	== Usage ==		== 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:		The following code demonstrates how to decorate a call with ringback tone and voicemail fallback behaviors:

Ktrueman: some clean up and new links

2009-07-06T18:42:55Z

some clean up and new links

← Older revision		Revision as of 14:42, 6 July 2009
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:		Here are examples of features that make good behaviors:
	*Ringback tones		*[[Ringback tones]]
	*Voicemail fallback		*Voicemail fallback
	*Follow me		*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		*CMyCall
	*CMyCallRingbackTone		*CMyCallRingbackTone
Line 34:		Line 34:
	== 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 shure a leg exists before using it. This should prevent crashes in case of invalid usage of the behavior.

Ktrueman: /* Usage */

2009-05-08T14:09:49Z

Usage

← Older revision		Revision as of 10:09, 8 May 2009
Line 22:		Line 22:

	== Usage ==		== Usage ==
	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 [[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 [[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.

	The following code demonstrates how to decorate a call with ringback tone and voicemail fallback behaviors:		The following code demonstrates how to decorate a call with ringback tone and voicemail fallback behaviors:

Ktrueman: /* Usage */

2009-05-08T13:55:51Z

Usage

← Older revision		Revision as of 09:55, 8 May 2009
Line 22:		Line 22:

	== Usage ==		== Usage ==
	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 [[TBCAF::CTBCAFCallBehaviorRbt\|CTBCAFCallBehaviorRbt]], [[TBCAF::CTBCAFCallBehaviorVoiceMail\|CTBCAFCallBehaviorVoiceMail]], [[TBCAF::CTBCAFCallBehaviorFollowMe\|CTBCAFCallBehaviorFollowMe]], [[TBCAF::CTBCAFCallBehaviorFaxRelay\|CTBCAFCallBehaviorFaxRelay]] classes are good examples of ~~all~~ 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 [[TBCAF::CTBCAFCallBehaviorRbt\|CTBCAFCallBehaviorRbt]], [[TBCAF::CTBCAFCallBehaviorVoiceMail\|CTBCAFCallBehaviorVoiceMail]], [[TBCAF::CTBCAFCallBehaviorFollowMe\|CTBCAFCallBehaviorFollowMe]], [[TBCAF::CTBCAFCallBehaviorFaxRelay\|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:		The following code demonstrates how to decorate a call with ringback tone and voicemail fallback behaviors:

Ktrueman: /* Usage */

2009-05-08T13:52:32Z

Usage

← Older revision		Revision as of 09:52, 8 May 2009
Line 22:		Line 22:

	== Usage ==		== Usage ==
	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 [[TBCAF::~~CTBCAFCallBehaviorRb~~\|CTBCAFCallBehaviorRbt]], [[TBCAF::CTBCAFCallBehaviorVoiceMail\|CTBCAFCallBehaviorVoiceMail]], [[TBCAF::CTBCAFCallBehaviorFollowMe\|CTBCAFCallBehaviorFollowMe]], [[TBCAF::CTBCAFCallBehaviorFaxRelay\|CTBCAFCallBehaviorFaxRelay]] classes are good examples of all 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 [[TBCAF::CTBCAFCallBehaviorRbt\|CTBCAFCallBehaviorRbt]], [[TBCAF::CTBCAFCallBehaviorVoiceMail\|CTBCAFCallBehaviorVoiceMail]], [[TBCAF::CTBCAFCallBehaviorFollowMe\|CTBCAFCallBehaviorFollowMe]], [[TBCAF::CTBCAFCallBehaviorFaxRelay\|CTBCAFCallBehaviorFaxRelay]] classes are good examples of all kinds of simple behaviors.

	The following code demonstrates how to decorate a call with ringback tone and voicemail fallback behaviors:		The following code demonstrates how to decorate a call with ringback tone and voicemail fallback behaviors: