2.1.1 What happens when I build or compile a WAM?
Let's review the process of building or compiling a WAM to see how this impacts the development process.
The easiest way to see what happens when a WAM is built or compiled is to create a simple WAM and review the resulting objects.
Let's use a very simple WAM (named KWAM10) with a single webroutine (KWAM1001):
The first time a Web Design is generated, the appropriate layout objects will be generated too. Any subsequent generation will NOT regenerate the layout objects. All changes to the generated layout are performed using the LANSA Editor.
Don't dwell on this too long as layouts will be explained in great detail later in this document.
The objects associated with the WAM layout are:
- A single layout variables object is created for the WAM – kwam10_layout.variables.xml
- A single layout XSL stylesheet is created for the WAM – kwam10_layout.xsl
Additional XML and XSL objects are generated or regenerated for each webroutine during the build or compile phase if you select the appropriate Generate XSL options in conjunction with one or more Technology Services. These XML and XSL objects can also be generated or regenerated for a specific webroutine when you explicitly ask them to be using the small green arrow immediately to the right of the RDMLX WEBROUTINE command. This set of objects will be created for each Partition Language and each selected Technology Service combination using the directory structure ...\X_WIN95\X_LANSA\X_<Partition>\web\<Provider>\<Technology Service>\<language>.
The objects associated with the Generate XSL settings are:
- An XSL stylesheet is created for each webroutine – kwam10.kwam1001.xsl
- A variables document is created for each webroutine. (This is related to the XSL object and is independent of the LXML information stored internally.) – kwam10.kwam1001.variables.xml
If you perform a build, the default system settings, to Generate XSL for all New Webroutines (that is, webroutines that have not previously had XSL/XML objects generated), will be applied. The compile options for a WAM allow more control of this process.
When compiling a WAM, the Generate XSL options allow for the generation of XSL to be bypassed, or XSL can be generated for All Webroutines or only for New Webroutines. You can also generate XSL for a single webroutine on demand using the small green arrow immediately to the right of the RDMLX WEBROUTINE command
It is important to remember that by selecting Generate XSL for All Webroutines you will regenerate the XSL and in doing so will lose any modifications applied in the LANSA Editor. The same applies when regenerating XSL on demand.
If you are doing Multilingual Development…
The XSL objects associated with the default partition language are published in the LANSA repository and replicated for other languages. This process allows you to effectively have a single set of XSL information for each Technology Service for all languages. While it is possible to have a different set of XSL published for each language, this approach is generally not recommended unless you require very distinct interfaces for each language. It is a better approach to use Multilingual Variables as this requires only one Web Design and hence is easier to maintain.
In addition to the XML and XSL objects generated, whenever a WAM is compiled (this does not apply for the build option) a set of RDMLX objects associated with the WAM will always be created or recreated. The same set of objects is created for a WAM as for any other RDMLX compilable object, for example:
A dynamic link library object kwam10.dll is created in the partition execute directory ...\X_WIN95\X_LANSA\X_<Partition>\execute
A program file, kwam10.pgm is created in the partition source directory ...\X_WIN95\X_LANSA\X_<Partition>\source
A text file, kwam10.txt is created in the partition source directory ...\X_WIN95\X_LANSA\X_<Partition>\source
That covers the files generated to support a WAM, but there is one final piece required to the complete the picture. When the WAM is built or compiled, LXML (a list representation of XML tags) information is ALWAYS generated, or regenerated, for each webroutine. This LXML information is stored internally in the LANSA database and is independent of Technology Service and Language.
Automatic regeneration of the LXML information is important as it ensures that any modifications to WEB_MAP definitions are available in the Webroutine Output tab. The LXML can be viewed in the LANSA Editor by selecting the XML tab.
Some modifications to the generated LXML (cookies and TSML nodes added by the LANSA Editor) are retained when the LXML is regenerated.
This is a concise view of the WAM build and compile processes. As you can see, in the diagram below, some objects are generated for the WAM and apply to all the webroutines in the WAM, while other objects are generated for each webroutine (and some information is stored internally):
