4 8 1 Paint Screen and Report Layouts Last

LANSA Application Design

4.8.1 Paint Screen and Report Layouts Last

As IBM i 3GL compilers require that display and printer files exist before the corresponding program can be successfully compiled, 3GL programmers are in the habit of designing screens or reports first.

When using LANSA, significant productivity gains can result by NOT following this conventional IBM i 3GL technique. Let LANSA design the screen and report layouts as you code, and then you can modify the layouts when you know that the program works.

Some points about this technique are:

  • When you need a screen to request or display information, think in terms of what you want to be on the screen, NOT where you want it on the screen.

   For instance if you need the user to input a part number and a customer number, simply code the following and and then keep writing the RDML program logic:

REQUEST FIELDS(#PARTNO #CUSTNO)

 

   What is initially important is that the user inputs the required information and that the program works correctly. The location of the information can be easily changed when the program is complete and functions correctly.

  • The same idea applies to defining report lines. Think of what is to be printed on the line, NOT where it is to be printed.

    For instance, if your report heading must include the date, time, company name and page number, then just code:

DEF_HEAD NAME(#HEAD01) FIELDS(#DATE #TIME #COMPANY #REP1PAGE)

 

   ..and keep on going. The detailed positioning of this information can be performed later when the rest of the program has been coded and tested.

  • If this idea is used on a large scale, the development of an application system will proceed at a much faster pace.
    It is also possible to actually "prototype" systems at a very rapid pace if this approach is adopted.
  • The final painting of screens and reports should be put off if possible - until the program involved is completely tested.
  • The final painting of screens and reports may be done by the system designer/analyst. An "end user" of the system may also be present to vet each layout in its final form.
  • An additional benefit of using this technique is that the online Full Function Checker (which is relatively expensive to run) need only be run once per program (i.e., when the time comes to paint the final screen and report layouts).