A way to de-couple client data from system data
Original Publication Date: 1999-Nov-01
Included in the Prior Art Database: 2003-Jun-20
Let the client code manage the client data by registering the data with a data agent/manager for printing, displaying, or reporting. When there is a need for printing, displaying, or reporting unique client data while performing printing, displaying, or reporting system data, letting the client code manage the client data by registering the client data with the data agent/manager will de-couple client data from system data. By using a client data agent/manager one can eliminate the constraint in assigning a range of identifiers for client's data pieces. This is because that sooner or later, the range will be filled up and clients will need more identifiers for new pieces of data. When the client code is registered with the system code of which client data agent/manager will be used, there is no limit of how many new data pieces a client can print, display, or report using the existing printing, displaying, or reporting mechanisms in the system code. For example, in SUREPOS ACE Electronic Marketing printing header/trailer messages on a customer receipt, the base code can raise an event when it encounters a generic token preceeding the place holder for the data, the token indicates client code is needed to process the message such as replacing the print variable with some client data. A client data agent/manager object can register for this event, and its event handling code will be called. At that moment, it can examine if it's supposed to provide the data. If it is not, it just ignores it; then another client code will in turn get a chance to examine if it's supposed to provide the data. If that client code determines that it's supposed to provide the substituted data, then it will provide that correct data and use the base code message formatting/printing mechanism to process the message. The message will be printed with correct data filled in. Most applications today possibly bundle client data and system data together by assigning data identifier ranges for different clients and some reserved ranges for system data. There are a couple of design patterns in the "Design Patterns Elements of Reusable Object-Oriented Software" book by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides such as Chain of Responsibility design pattern and Decorator design pattern that have similar purposes of de-coupling the system and the client. However, they are for adding additional behaviors, responsibilities to an object. The claimed invention's purpose is to deal with data not behaviors. Moreover, in the Chain of Responsibility pattern, a function handler object must know a successor in the chain to call; in the claimed invention, diffrent client data agent/manager objects can exist independently.