Customer Application Framework
(added category) |
(Added link to page 'Working with Call Legs') |
||
| Line 9: | Line 9: | ||
Of course the framework will not address all of the clients needs perfectly. This is why most of the classes may be subclassed or re-implemented to provide a better fit and still be used in the rest of the framework. For example the data access object for a client account may be reimplemented to query a non supported database. This DAO could then be used in the gateway application with minor modifications. | Of course the framework will not address all of the clients needs perfectly. This is why most of the classes may be subclassed or re-implemented to provide a better fit and still be used in the rest of the framework. For example the data access object for a client account may be reimplemented to query a non supported database. This DAO could then be used in the gateway application with minor modifications. | ||
| + | Refer to [[CAF:_Working_With_Call_Legs|Working_With_Call_Legs]] for details on how to work with call legs. | ||
==References== | ==References== | ||
Revision as of 08:56, 18 January 2011
The Customer Application Framework (CAF) library comes in where the CMC library left off. The main purpose is to provide a set of optional C++ classes that may be used to easily implement gateway applications. The CAF classes build on CMC legs and provide easier management of calls, CLI, memory, logger, database, etc. CMC samples and applications are built on this framework since the code is easier to understand and the development time is shortened.
The optional nature of CAF
Clients should not need to integrate in a really big framework just to use one of the framework's helper classes. This is why each individual element of the framework is designed to be optional and independent. For example it is not mandatory to use a routing class to create a call class.
The customization of CAF
Of course the framework will not address all of the clients needs perfectly. This is why most of the classes may be subclassed or re-implemented to provide a better fit and still be used in the rest of the framework. For example the data access object for a client account may be reimplemented to query a non supported database. This DAO could then be used in the gateway application with minor modifications.
Refer to Working_With_Call_Legs for details on how to work with call legs.
