Definition files provide information about the "known" screens in an application. At runtime, a Flynet Viewer component will read one or more definition files in order to maintain an internal "dictionary" of screen information.
With a hierarchical screen identification system (using nested ScreenGroup and Screen tags), a definition gives a developer a powerful method of organizing and recognizing "which screen is currently displayed". With the provided COM or .NET ViewerLib interface, a developer can rapidly implement robust screen navigation sequences that exploit definitions using the waitForScreen and getScreenName methods.
The FieldMap and Field tags enable one or more field mapping objects to be associated with each screen. The mappedGet, mappedSet, mappedRowGet and mappedRowSet methods in the HostScreen object may then be used to access fields "through" the XML-based definition rather than with specific row/column coordinates.
By maintaining as many details as possible in a definitions file, the developer insulates him or herself from formatting changes made to screens. If a field moves on a screen, a change can be made directly to the FieldMap describing the fields on that screen. A search does not need to be made across all scripts accessing the screen in order to locate all change requirements for the screen. With only screen coordinates, such as row, column used to identify a field, making the location of required changes can require detailed walk-throughs without the organized use of a field map.
With a definitions file as the sole source for screen identification and field locations, change management is facilitated and the impact of changes is minimized.
