6.4 The Component Model
Visual LANSA extends the LANSA repository to include components in addition to fields and files. This object-oriented component model provides the foundation for user-centered, event-driven applications. However, in Visual LANSA the object-oriented paradigm is implemented in a simple way to allow you to focus on productivity and business goals.
The component model is the foundation for future application development with LANSA.
Fields Become Components Automatically
All your existing LANSA fields become components automatically. By default all fields become entry fields. This means that when you want to use a field in an application, you drag it from the repository to the form and it is automatically visualized as an entry field with a label. All rules and triggers are applied as usual. Because the entry field is a component, it has properties such as height and width and associated events.
You can also modify the component definition of a field to make it appear as a spin edit box, an entry field with a prompter, a check box, a set of radio buttons, a list, a track bar or a a progress bar.
The automatic conversion of fields is a major benefit because you do not need to resize and redefine countless attributes as you do when moving from the IBM i to many other visual tools.
The component characteristics of a field are ignored when you use them in your LANSA for i or universal UI applications.
Reusable parts
Component technology is designed to provide productivity, quality and consistency gains by centering the development effort on the creation of standard, reusable, automated building blocks, called reusable parts, from which applications are assembled. As much of the maintenance is carried out at the reusable part level, the time required in testing and verifying individual applications is also greatly reduced.
A typical Visual LANSA application is built from a number of reusable parts defined in the repository, such as lists, fields and standard dialogs. You can change an individual reusable part and this change is reflected in every application that uses the component—the applications themselves do not need to be changed or recompiled. For example you could change the label of a reusable part and this change would be reflected immediately in every application where the button is used.
Reusable parts can contain logic. You could, for example, create an automated reusable part called EmpList, define it as a list box and write the code to fill it from a specific database table.
|
|
|
After creating this component, you would reuse it in every application that needs this list of employees. Because the component uses its own code to fetch the entries from the file and display them, no coding is required to fill the list in the application itself.
Later on you could change the part to also display for instance an employee number in the list. Or if the employee information was moved to another file, you could simply change the file name in the SELECT statement of the component. You would then recompile and test the component and store it back in the repository. Again, all these changes would immediately be reflected in every application in which the component is used, without having to recompile and test them individually.
By using reusable parts, you can be sure that your applications look the same and behave the same way. For example by using a standard set of OK and Cancel buttons, you know that your buttons on every screen are the same size, shape and color, have the same caption in the same font and behave consistently.
You can create your reusable parts from scratch or you can copy and modify existing ones. Once you have a standard set of components for your site, creating new applications and extending existing applications becomes a matter of simply assembling together the required parts.