Controlling the Appearance of the Application
This example was created using an HTML skeleton. The advantage of using a skeleton is that it removes the need for most (if not all) of the HTML editing after each LANSA recompile of a function.
This example was created using an HTML skeleton. The advantage of using a skeleton is that it removes the need for most (if not all) of the HTML editing after each LANSA recompile of a function.
- We started off by designing the layout using only HTML and hard coded values. The layout consists of the left menu and the body composed by the header with the banner, text and the footer.
- Once that was done, we created the skeleton (WRKMBRPDM FILE(SETDTALIB/DC@W22) MBR(SET_175)) and pasted in the HTML.
- The background and layout of the left menu is a simple image called shippingbg.gif . It is just a horizontal line with different colors. The browser automatically tiles the image so you get the effect the background in the whole page by using the BACKGROUND html attribute in the BODY tag like this: <BODY BACKGROUND="<RDML MERGE="*LW3SETSHIPPINGBG">"
- The contents of the left hand menu are laid out in the component S_175MENU. I created a field called S_175MENU in the repository and included it in all the PANELDATAs of all the functions as *hidden.
- In the skeleton, where it says %W3FLD, LANSA will put the fields in your request command
- In the skeleton, where it says %W3BRW, LANSA will put the browselist
- In the skeleton, where it says %W3FRM LANSA will put the FORM tag
- The <RDML ONCONDITION="STD_FLAG"> controls the insertion of the map so that it only happens in the main page. Hence, in function SET175B I included it in PANELDATA and set the value to non blank. The other functions don't have it so it will be blank and the html enclosed will not be sent.
- The same occurs with the flag BR_FORMAT which controls the formatting of the column headings only for the schedule browselist (S_175VVP). The graphical variable *LW3BL_S_175VVP with *NOC removes the column headings which appear in that table between the oncondition. The WIDTH=550 in *LW3BLMS_S_175VVP controls the width of the browselist (that width is appended to the table tag that LANSA for the web creates for the brw). In the skeleton then the you see the same width for the column heading table. You can also see the width of the TD for the Port string as 106 and the rest with COLSPAN="4" (span the other four columns of the dates) and WIDTH="440".
- 440 + 106 = 546, there are four pixels used by something else.
- The background and foreground colors of the browselist headers and cells were controlled with the graphic variables beginning with *LW3BLBC, *LW3BLCCB, *LW3BLCCF and *LW3BLFC.
- Each function has header text specific to it. So we created a field called S_175FDES which has a default of “*FUNCTION”. We created one visual input component for each function with the same name as the function, containing the header text for that function. In the skeleton you will see the line <RDML COMPONENT="&FLD_S_175FDES"> which means replace what's between the double quotes with the contents of the field S_175FDES which will be the name of the current function and so the components with those names will be used.