In the 5250 environment, the record formats that describe the user interface exist inside the display files. At run time, your system resolves the record format requested by a program by searching for the display file in a fully qualified library or in a library in the library list. In the WebFacing Tool, this works differently. The WebFaced application does not use a display file located in the native OS/400 system, so a different way of resolving record formats is required.
Until now, the mapping of your record formats at run time has been successful because I used the default name when creating the display file, which is the member name of the DDS source member. The WebFacing Tool assumes at run time that this default has been used. Therefore, the WebFacing run time can easily find the correct .jsp file that represents the requested record format.
You need to examine the files that the WebFacing Tool created during conversion of the Order Entry application. Figure 11.1 shows the directory structure of your WebFacing project in the Navigator view.
You can see that the created folder structure is a duplicate of the DDS source environment structure, used by the Order Entry application. The library name, source file name, and member name are all part of this structure. The .jsp file has the name of the record format itself. When running the application, WebFacing run time uses this structure to find the correct record format requested by the program.
As mentioned before, this works as long as the run-time environment reflects the development environment. However, this is not always the case. To give you more flexibility to reflect your real run-time environment, you can specify mapping rules with the WebFacing Tool.
This exercise shows you how to specify a mapping rule for a display file, when the display file does not have the same name as the source member from which it was created.