 |
Control : DynamicFormFrom $1Table of contents
The DynamicForm control enables you to embed one or more forms within another.
OverviewThe DynamicForm control lets you embed one or more forms within another form. The control can switch between different forms at runtime (depending on user choices and application state), allowing you to create extremely powerful, dynamic user interfaces. CapabilitiesUse the DynamicForm control to: Limitations
Requirements
ExamplesThe following examples are intended to be used with sample code that you can import into your Bungee Builder workspace from the Start Page. Each example is intended to build upon the previous example to provide you with a complete understanding of how to use this control. Example 1: Simple Embedding of Forms (Ex1_Person)You can embed a form within another form based on the DynamicForm control's Form property (Interface tab). The easiest way to implement this is to bind the DynamicForm control to a complex field that you wish to display. Add a form to the class on which the complex field is based, and design the form as you wish it to appear inside the DynamicForm control. Then add a form interface to the project TypeLib, and assign the form interface to the custom form's Interface List property (General tab). Finally, assign the DynamicForm control's Form property (Interfaces tab) to use the same form interface. In this example, the DynamicForm control is bound to the examplePerson field, which is a complex object based on the Person class. A standard control interface represents this in the accompanying diagram. The Person class contains two forms—one called detail, another called readOnlyDetail. In order to select which form to use for the examplePerson field, the DynamicForm control is explicitly configured to use a form interface called Detail_FA. That causes the detail form to display at runtime because the detail form's Interface List property (General tab) lists the Detail_FA form interface. Note Functionally, forms are always view components. However, because the detail and readOnlyDetail forms are encapsulated in the Person class, they are referenced like Model components. Encapsulation of view components within the object model enables you to re-use forms in several powerful ways (such as inheriting a form from a superclass, or re-using a form within various of other forms). A few of these are shown in the subsequent examples.
Example 2: Switching Between Forms to Display Different Data Types (Ex2_CurrentObject)You can use the DynamicForm control to display different types of data by assigning a form for each data type to the same form interface. Note Before continuing, simulate the form Ex2_Detail to see this in action. Change the object type in the combo box and see how the interface dynamically changes. The basic design pattern for this example starts by adding an appropriate form to the class definition of each data type that you want to display. Assign each of these forms to use the same form interface in their Interface List property (General tab). Next, bind the DynamicForm control to a polymorphic field—that is, to a field that can become any of the data types that you intend to display. This requires the field to be based on a superclass to all the objects that you intend to display in the DynamicForm. Finally, assign the form interface to the DynamicForm's Form property (Interfaces tab). With this configuration, you can now use some basic application logic to assign different objects to the polymorphic field, causing the DynamicForm control to use the form interface to select the appropriate form each time the data type in the polymorphic field changes. The example code shows a simple implementation of this design pattern. The DynamicForm control is bound to a field named currentObject. This field is based on a generic object type named Object, which is a superclass to all object types. There are three other fields—exampleAddress, exampleEmployee and examplePerson—each of which is based on a separate, custom class. In order to supply the example with data at runtime, these three fields have been set to instantiate themselves with some arbitrary default data. The Combobox control on the form is bound to a field called objectType (for which enumeration has been set with three possible options). When the value of the field changes, the change in value triggers the field's OnChange code to execute. (Double-click the objectType field to view this code.) The OnChange code then assigns the values from one of the three instantiated fields to the currentObject field. This assignment changes not only the values of the currentObject field, but also changes the type of data it contains. This change in type causes the DynamicForm control to switch forms according to its assigned form interface, Detail_FA. Whichever form in each of the three possible classes (Address, Employee, and Person that is assigned to the Detail_FA form interface, is then used to display the current object.
Example 3: Switching Between two Different Forms for the Same Data Type (Ex3_PersonChangeForm)The DynamicForm control can display different views of the same class, depending on application state, by switching between two or more forms for that class. Note Before proceeding, simulate the form Ex3_PersonChangeForm. Use the Combobox to switch between a read-only and an editable view of the same object. This example closely follows Example 1. A Combobox control is bound to the formType field, on which two enumeration values have been configured. A DynamicForm control is bound the examplePerson field, which is configured to instantiate at runtime with some default data. However, the control does not have a form interface assigned to its Form property (Interface tab). Instead, it is configured to use a DynamicForm Interface called ReadOnly_or_Editable on its Dynamic property (Interface tab). This DynamicForm Interface assigns the DynamicForm control to follow the logic in a DynamicFormAdapter in order to select which form interface (and consequently, which form) to use. The DynamicFormAdapter, located in the Person class, uses Model code to assign which form interface to use. (Double click the DynamicFormAdapter object to view its configuration in the Design Editor.) The model code is set to trigger whenever the formType field changes. When triggered, a case condition assigns the correct form interface according to the value of the formType field.
Note It is important to make sure that you set the Trigger property on the Model header of the Model code, or the change in value will not cause the desired interface change. The Model-View-Interface diagram for this shows the two Control Interface bindings as you would expect. The DynamicForm Interface is represented by the design view of the DynamicFormAdapter to which it links in the Person class.
Example 4: Switching Forms According to Multiple Changes in Application State (Ex4_CurrentObjectChangeForm)The DynamicForm control can trigger off of both the bound object's type and a field that assigns which form interface the DynamicForm control should use. This example combines elements from the previous two examples to let the end user, at run time, select the object bound to the DynamicForm control as well as which form to use. Combining these two concepts allows you to make very sophisticated interaction scenarios in your applications. Note When inspecting the example code, observe that example class Ex4_CurrentObjectChangeForm inherits directly from Ex2_CurrentObject, which provides it several of its fields and other components.
ReferenceFrequently-used OptionsSome of the most commonly used properties that apply to the DynamicForm control are:
Supported Types (Control Interface)
Default Interfaces
Adapters
Associated PropertiesSpecialized PropertiesUnique Properties
Tags:
|
||||||||||||
