The Graphical Framework uses the following basic objects:
The data container is a container holding data for the application. It contains objects that have an unambiguous ID; the rest of their structure can be defined according to requirements. The graphics proxy takes the required data from the data container and displays it in the graphic. Since several graphics can subscribe to a single data container the data to be represented needs to be stored only in one place. Every change affects all the graphical objects concerned automatically. Data containers implement a specific interface. This means that an application development team can implement its own data container so long as it implements the defined interface (the interface methods must be implemented in the data container). For more information, see Data Container.
A proxy acts as a defined interface and transport layer between objects - in this case between the data container and the application (in the back end) and the graphic (in the front end). Proxies generally have additional logic and cache functionality. Given the well-defined interface in the back end the application programming is independent of the graphical object that is in the front end.
The graphics proxies need to be adapted to the requirements of the application. Since they are objects they can be implemented in a more detailed form and enhanced with additional logic. For more information, see Graphics Proxy.
The multiplexer relieves the application of the following tasks:
Handling of external program graphics
The multiplexer ensures that several program graphics can be displayed at the same time (one endless loop only) and that their events continue to be processed correctly.
Synchronizing the graphics proxies with respect to specific events
The multiplexer sends an event processed by one graphics proxy to another (for example, to synchronize several graphics proxies on a time axis, to scroll several graphics simultaneously or to synchronize Customizing). It is important to point out that events within the Graphical Framework are product-independent. For more information, see Multiplexer.
The display attributes are bundled into customizing objects so that the user can change the settings of all graphics flexibly (and individually). The appearance of the graphics is determined by assigning these customizing objects to ports in the graphics proxies. The attributes defined in the customizing object can be overridden by user-specific values. For more information, see Customizing Objects.
A graphics proxy can support several graphics products in the front end. There is a part of the Graphical Framework known as product management that specifies the product and the priority to be used on specific operating systems. The priority can be adapted for the company using the SAP system. For more information, see Product Management.
Standardized function modules
There are some simple graphics with a standardized layout and no interactive functionality. To simplify the programming you can use function modules to display such graphics. There is a function module for every graphics type that encapsulates the powerful functionality provided by the objects described above (data container, graphics proxy and so on). For more information, see Function Modules Supported.
Data container wizard
The user can implement an application-specific data container using a standard program (GFW_DCWIZARD) belonging to the Graphical Framework. The program generates appropriate ABAP source code for a given DDIC structure. For more information, see Data Container Wizard.