Rich Data Definition Builder

Rich Data Definition Builder

In this topic ...

How do I...
Specifying Inputs
Using this Builder
Localizing Data Definitions

This big advantage this Builder provides is that it allows you to control all aspects of field-level UI in a centralized, automated way. This Builder accomplishes this by adding UI "data definition" information to fields in a schema. This information includes most settings from Data Field Modifier Builder, plus additional settings. The Data Page Builder will use this information to construct any pages based on the schema.
We can use this Builder to globally control the following UI elements:

Field Labels
Display Status (Required, Hidden, and Read-Only)
Display mode (Vertical or horizontal)
Data type - (Int, String, etc.)
Enumeration values
Formatting, Validation, Translation
Custom formatter class
Field order and field removal

When you use this Builder you associate a description called a "Data Definition" from an XML file (or from this Builder's UI) with an element in a schema. With a data Definition file we can control:

Grouping - Create grouping from flat structure
Data Entry and Display Control - Including any Builder Inputs, like settings for Calendar Picker
Lookup Table Use - Including Builder Inputs and the ability to invoke an additional Builders (create Lookup from Service Consumer Builder)
Attributes - Most HTML attributes
ColumnWidth, ColumnAlignment, ColumnSorting

Once you have applied this Builder to a schema, any pages that are based on the schema (whether tabular, view-only, or editable) automatically inherit all the characteristics specified by this Builder. Any Data Definition for a field can inherit from another Data Definition, using the "base" attribute. The base Data Definition can be in the same file or in a library file, and any Data Definition file can specify a base definition file.
One advantage placing common Data Definitions in a shared base library is that doing so enables you to use the definitions wherever you want and make global changes to a page. For example, you can have a single Data Definition element that controls formatting of all "SAP Date" elements. This Data Definition could specify:

Formatting - Including localization support
Translation - To/from the internal SAP format
Data Entry control type - To automatically use a JavaScript calendar picker widget

A sample model illustrating the use of this Builder is included in the "Tutorials and Samples - Applications" Feature Set. Once you install this Feature Set, open: .../ WEB-INF/models/samples/datapage/RichDataDefinition.model. Refer to the Comment Builder describing this model for additional information about how the Rich Data Definition Builders in the model are configured and used.
We can specify a comma-delimited list of enumeration values in many inputs. You might want to do this to use the list of values to generate a SELECT input.

How do I...

Change the format of a date or other type of field?

Place a Rich Data Definition Builder in a model that contains the schema you want to modify. In the Builder's editor select the Schema. Use the Builders Data Definition editor to select a field. Once a field is selected, modify any data definition properties required. For example, provide a label change the data type, select a formatting, translate or validate expression, require or hide the field, and more. Select another field and specify additional changes. Click Apply or OK to apply you data definition changes.
Create a Data Definition file for reuse?

Place a Rich Data Definition Builder in a model that contains the schema you want to modify. In the Builder UI select the schema and use the Data Definition Editor to map changes to various fields. Once you've completed all the changes required, press the "Create Data Definition File" button. Provide a name and save location for this XML file when prompted and press OK. The Builder will create an XML file containing the data definitions you've specified.

Specifying Inputs

This Builder takes the inputs described in the table below. For help on inputs common to many or all Builders such as those in the Properties input group, see "Using the Builder Call Editor"

Input Name Description
Schema Select a schema that contains the fields you want to modify.
All schemas in the model will be displayed in the select list.
Data Definition Type The data Definition Type defines the mechanism used to convert schema elements into another format. We can Choose:

Read data Definition File - To apply an existing file of conversion properties to the schema.
Specify Data Definitions in Builder UI - To manually enter in this Builder's editor individual properties that will be applied to the schema. (Note: The Builder will create a file containing your entries if you so choose. See, "Save Sample Data Definition File" below.)

Data Definition File This input is available when the Data Definition Type is "Read Data Definition File."
Use it to specify an existing XML-based Data Definition File to apply to the schema.
Base Data Definition File This input is available when you choose "Specify Data Definitions in Builder UI"as the Data Definition Type. (This input is hidden when "Read Data Definition file" is selected as the Data Definition Type above, and the base file is specified within the file.)
Use this input if you want the Data Definition File to inherit properties from another (Base) Data Definition File. Select the Data Definition File to be used as the parent Data Definition File from which properties will be inherited.
We can set the base in the XML file, directly under the root DataDefinitions element as follows:
<BaseDefinitions>
      <BaseDefinition>/samples/datapage/base_datadef.xml</BaseDefinition>
</BaseDefinitions>
Reorder Elements Enable this check box to reordered fields in the order you specify.
Data Definition Editor
Container Element Choose the schema Container Element you want to edit.
We can choose any schema container schema element that contains "leaf" nodes. In some cases, such as a Domino view or a SQL table, you will have only one choice. In other schemas, such as for SAP, the data might display a number of container elements.
Fields For each field in the schema, we can specify some or all of the following conversion properties.

Label - Alternate text string for display
Base Data Definition - Data definition with "BASE" attribute set. Field settings will be inherited from this base definition.
Required - Enable to make the field a required field. This field must contain a user entry.
Data Type - Select a data type for the field.
Enumeration Values - A comma-separated list of choices
Hidden - Enable to hide the field.
Read Only - Enable to make field a display field. No data can be entered in such a field.
Formatting Expression - Select a format for the field from the list of formats. For example, if you choose the format expression DateTimeFormat(FormatString) the string "FormatString" will be replaced with the evaluated version of what the user entered in the Format Expression Argument input before it is passed to the Formatter.
Validate Expression - To provide data entry validation of the field, select a validation expression. Choose one of the validate expressions to apply to the field data being submitted. The validate method implements server-side validation and operates on the value returned by the translate method (if translate is used). Note that the following date comparison methods are available to support date validation: Date>today,    Date>=today,   Date=today,   Date<=today,   Date<today.
Translate Expression - Choose one of the available translate expressions to apply to the field data being submitted. Translating refers to modifying user input for storage as data. For example, a user may insert dashes when entering a Social Security number in a form. A translate method could remove the hyphens from the user input, creating a value that can now be stored as data. Similarly, the "Credit Card 16 digit" expression removes "-" and " " from a string and ignores errors.

Save Sample Data Definition File
Create Data Definition File This input is available when " Specify data Definitions in Builder UI" is selected as the Data Definition Type.
Push this button to create an XML-based Data Definition File that contains the properties you have specified in the Fields editor.
You might want to do this to create a reusable library file of the data definitions you've specified.
You will be prompted to name the file and provide a save location.
Advanced
Data Definition This input is available when " Specify data Definitions in Builder UI" is selected as the Data Definition Type.
We can use this input to profile data definitions that are not supported or displayed in the Builder's UI.

Using this Builder

To grasp the power of this Builder consider a typical page in which column labels are returned from the database. You might see the following labels: DATE_ORDERED, STATUS, DATE_SHIPPED, etc. Returned labels are all uppercase and multi-word labels are conjoined with an underscore. Using this Builder we can substitute reader-friendly initial-cap labels ("Date Ordered", etc.) for uppercase labels to make your forms look better.
In addition, for form fields that can return one of a set of boiler-plate labels, we can specify a page control to display the label that applies. For example, on a field that returns ORDER_STATUS, you might specify a radio button group that displays all possibilities (such as : Shipped, Out of Stock, Returned, In Process), with the radio button representing current order status enabled.
For a "STATE" form field you could even create a Select List page control (labeled "State") that has the customer's state selected and displayed.

Working with Data Definitions

Data Definitions can be read from an XML file or specified directly in this Builder. The Builder also has a button that will create a Data Definition file for you, based on the schema and including any changes you made to the schema in the Builder UI.
This Builder modifies the Data Definition information that can be associated with a schema in a WebApp. Data Definition is one of the internal data structures of the Data Page Builder. When Data Page is used with a schema-typed variable, it looks for any Data Definition information attached to the schema in the WebApp. Those Data Definition properties become the defaults for any pages based on the schema. However, we can still use other Builders such as Data Field Modifier to override the properties specified in the Data Definition of the schema.
The association of Data Definitions to schema elements is done using the element name. A Data Definition file typically stores a set of structures, with a child Data Definition for each field in the structure. The parent (structure) name in the schema must match the parent name in the Data Definition file, and then the individual fields are also matched by name.

Inheriting Data Definitions from a Base Definition File

The "base" attribute can be used to inherit properties from other Data Definitions. The inherited Data Definition can be in the same XML file, or it can be in the "Base Data Definition File" specified in the Builder. Data Definition properties are inherited at the individual property level, and any properties can be overridden in the derived Data Definition.
For example, here are two of the definitions for typical data fields (QUANTITY and DATE_ORDERED ):
<DataDefinitionElement name="QUANTITY">
<Label>Quantity</Label>
<Required>false</Required>
<ValidateExpr>Optional integer</ValidateExpr>
</DataDefinitionElement>

<DataDefinitionElement name="DATE_ORDERED" base="base_SAPDate">
<Label>Date Ordered</Label>
</DataDefinitionElement>
The base "SAPDate" definition used for DATE_ORDERED might look something like this:
<DataDefinitionElement name="base_SAPDate">
<DataEntryControl>com.bowstreet.solutions.wfm.builders.CalendarPickerBuilder</DataEntryControl>
<DataEntryInputs>
<Inputs>
<Input name = "Format">MM/dd/yyyy</Input>
</Inputs>
</DataEntryInputs>
<FormatExpr>Format(yyyy-MM-dd$MM/dd/yyyy)</FormatExpr>
<TranslateExpr>Translate(yyyy-MM-dd$MM/dd/yyyy)</TranslateExpr>
<ValidateExpr>Optional Date(yyyy-MM-dd)</ValidateExpr>
</DataDefinitionElement>

Create Groups of Fields

In the XML file, we can create grouping of fields. To do this, create group definitions directly under the root DataDefinitions element. A typical group definition might looks as follows:
<DataDefinitions>
   <GroupDefinitions>
      <GroupDefinition name="Personal">
      <Label>Personal Information</Label>
      </GroupDefinition>
      <GroupDefinition name="Address">
      <Label>Address</Label>
      </GroupDefinition>
   </GroupDefinitions>
   <DataDefinition name="Members">
      <Required>true</Required>
      <Children>
         <DataDefinition name="first">
            <GroupName>Personal</GroupName>
            <Label>First Name</Label>
            <Required>true</Required>
            <DataType>string</DataType>
         </DataDefinition>
         <DataDefinition name="last">
            <GroupName>Personal</GroupName>
            <Label>Last Name</Label>
            <Required>true</Required>
            <DataType>string</DataType>
         </DataDefinition>
         <DataDefinition name="states" base="base_US_States">
            <GroupName>Address</GroupName>
            <Label>States</Label>
            <Required>false</Required>
         </DataDefinition>
         <DataDefinition name="birthdate" base="base_date">
            <GroupName>Personal</GroupName>
            <Label>Date Of Birth (MM/DD/YY)</Label>
            <Required>false</Required>
         </DataDefinition>
         <DataDefinition name="birthtime" base="base_time">
            <GroupName>Personal</GroupName>
            <Label>Time Of Birth (HH:MM AM/PM)</Label>
            <Required>false</Required>
         </DataDefinition>
         <DataDefinition name="salary">
            <GroupName>Business</GroupName>
            <Label>Salary</Label>
            <Required>false</Required>
         </DataDefinition>
      </Children>
   </DataDefinition>
</DataDefinitions>
Here <GroupDefinitions> elements set up individual groups of fields under corresponding <GroupDefinition> elements.

Using Data Definition Properties

Various Data Definition properties can be included in Data Definition XML files. These properties are not exposed in the Builder Call editor, however. To use these properties add them directly to the XML file. A sample model incorporating data definitions that will illustrate these techniques can be found at: WEB-INF/models/samples/datapage/RichDataDefinition.model.
A corresponding XML file is located in the project to which you've added the "Tutorials and Samples - Applications" Feature Set. This file is in the: ..../<workspace_name>/<project_name>/samples/datapage/orders.XML directory.

Property Description
<Attributes> Attributes takes an XML value which is the same as the Data Field Modifier Builder takes. A typical Attribute property looks as follows:
<Attributes>
   <Attribute>
       <Name>color</Name>
       <Value>black</Value>
   </Attribute>
   <Attribute>
       <Name>size</Name>
       <Value>${Variables/CurSize}</Value>
   </Attribute>
</Attributes>
<ColumnAlignment> Takes one of the following values: "left" "right" "center"
<ColumnSorting> Takes one of the following values: Case Insensitive String, Case Sensitive String, Number, Date, Not Sortable.
A typical data definition element using some of the above properties to set column width, alignment, sorting status and style might look as follows:
DataDefinitionElement name="DATE_SHIPPED" base="base_SAPDate">
    <Label>Date Shipped</Label>
    <Required>false</Required>
    <ColumnWidth>400</ColumnWidth>
    <ColumnAlignment>right</ColumnAlignment>
    <ColumnSorting>Case Sensitive String</ColumnSorting>
    <Attributes>
        <Attribute>
            <Name>style</Name>
    <Value>color:red</Value>
        </Attribute>
    </Attributes>
</DataDefinitionElement>
<ColumnWidth> Takes a number that represents with width of the column in characters.
<DataEntryControl> This property associates a Builder ID with a field, when the field is on a data entry page (see Display Control for view-only pages). You can specify both the Builder ID and any builder inputs that are needed. To create XML for the builder inputs, we can use the builder you want in a model, then go to the Model XML view, then copy/paste from the "Inputs" section of the XML. Note that the builder must support an indirect reference input called "Value" in order to be used. For example:
<DataEntryControl>com.bowstreet.builders.webapp.TextAreaBuilder</DataEntryControl>
     <DataEntryInputs>
          <Inputs>
              <Input name = "Wrap">off</Input>
              <Input name = "Cols">80</Input>
              <Input name = "Rows">5</Input>
           </Inputs>
     </DataEntryInputs
<Display Control> This property is similar to Data Entry Control, but for view-only pages. The corresponding element name for builder inputs is called <DisplayInputs>.
<DisplayMode> Allowable values are:

0 - DISPLAY_NONE
1 -DISPLAY_AUTO

Additional values for container fields include:

2 - DISPLAY_VERTICAL
3 - DISPLAY_HORIZONTAL

<EnumerationValues> We can use this property to set the choices for a field that has a set of possible values. This property does not provide for separate text/values such as lookup table does.
See note below regarding localization of enumeration values.
A typical use this property might look as follows:
<EnumerationValues>
   <Value>Shipped</Value>
   <Value>Out of Stock</Value>
   <Value>Returned</Value>
   <Value>In Process</Value>
</EnumerationValues>
<FormatterClass> We can use this property to specify a custom formatter class in a Rich Data Definition file. The formatter class uses the same mechanism and interface as is Data Field Modifier builder.
The name of the formatter class is specified with a "FormatterClass" element as shown below.
<DataDefinition name="AMOUNT" base="base_Currency">
<Label>Amount</Label>
<ColumnSorting>Case Sensitive String</ColumnSorting>
<ColumnWidth>100</ColumnWidth>
<ColumnAlignment>right</ColumnAlignment>
<FormatterClass>com.bowstreet.samples.DashboardFormatter</FormatterClass>
</DataDefinition>
<InitialValue> This can be used to define a default initial value for a field. It is equivalent to setting the "Initial Value" input of the Data Field Modifier Builder.
<LookupTable> We can use this property to create a lookup table and associate it with a field. To create a new lookup table, specify the Builder s ID, and the Builder must be one that creates a lookup table in the WebApp (Lookup Table, Domino Keyword Lookup, or SAP Help Values). Specify all the required builder inputs in the "Inputs" element as shown below.
This example code creates a lookup from XML data using the Lookup Table Builder. This functionality has also been used to automatically create and apply an SAP Help Values lookup.
<DataDefinitionElement name="BILLING">
    <Label>Billing</Label>
      <LookupTable>
         <BuilderID>com.bowstreet.builders.webapp.LookupTableBuilder</BuilderID>
             <Name>billing</Name>
                <Inputs>
                   <Input name = "DataType">NewXmlData</Input>
                   <Input name = "GetDataFrom">BuilderInput</Input>
                   <Input name = "TablePosition">InFront</Input>
                   <Input name = "Name">billing</Input>
                   <Input name = "NewXmlData">
                        <lookup>
                          <entry>
                              <name>Purchase Order</name>
                              <value>1</value>
                          </entry>
                          <entry>
                              <name>Credit Card</name>
                              <value>0</value>
                          </entry>
                        </lookup>
                   </Input>
                   <Input name = "ValueElementName">value</Input>
                   <Input name = "LabelElementName">name</Input>
                </Inputs>
        </LookupTable>
</DataDefinitionElement>
Click here for information about creating a lookup table when calling a Builder that does not automatically place a lookup table in the WebApp
<Properties> Use this property to set any named property on a DataDefinitionElement. This tag is designed primarily for people making their own Builders, when they want to add new properties to the Data Definition and to access those properties from Builder code. The Properties element looks as follows:
<DataDefinition name="AMOUNT">
          <Label>Amount</Label>
               <Properties>
                   <Property name="ColumnWidth">100</Property>
                   <Property name="ColumnAlignment">right</Property>
               </Properties>
</DataDefinition>
In this example the name= attribute specifies the property name and the element text contains the property value. Note that the technique illustrated in this example has the identical effect as using the ColumnWidth and ColumnAlignment property tags directly.
<ReadOnly> Forces a field to be treated as read-only, even when field is displayed with a Data Page that is marked "Data Entry".
Effect is equivalent to setting the "Field Behavior" to "View Only" with the Data Field Modifier builder.
<Remove> Specify a value of "true" to remove a field. The field will not be visible, nor will it be displayed in other Builders such as the Data Column Modifier or Data Field Modifier.

Localizing Data Definition Properties

We can localize most of the properties or Builder inputs specified in a Data Definition file using a resource bundle. The resource bundle is loaded using language and country information from the Localized Resource Builder, if one is used in the model. To use resource bundle values, first set the "resource" attribute in the root element of the Data Definition file. A typical example looks like this:
<DataDefinitions resources="com.bowstreet.solutions.wfm.base.datenumber_formats">
You then add a "resource_key" attribute for any properties in a Data Definition. For example, the following is used to look up the date format string from a localized resource bundle:
<FormatExpr resource_key="base_sap_date_format_expr">Format(yyyy-MM-dd$MM/dd/yyyy)</FormatExpr>
Note: We can not localize the <EnumerationValues> property by specifying a resource_key in the data definition file. Enumeration Values are accessed via a   direct mapping to the Data Definition / PageAutomation Leaf.setEnumerationValues() functionality. This mapping does not support label/value pair, but rather just a java.util.List of Values.

Create a Lookup Table

To define a lookup where the values come from a Builder that does not itself create a lookup, we can specify an additional Builder to call. The example below uses a Service Consumer Builder. In this case suppose you want to create a Lookup Table from the Service Consumer. We can do so if you add the ServiceInfo child element to the LookupTable element, and specify an additional builder that supports getting the lookup data. Then the Lookup Table Builder specified in the data definition can reference the data returned by that other builder.
The end result is that the data definition file will cause any number of fields (in every model that references the data def) to be automatically populated with a drop-down lookup, where the values are dynamically retrieved by calling a service. For example, the following XML can be used to invoke a Service Consumer Builder to dynamically get lookup values, and then reference the results value in the Lookup Table Builder:
<LookupTable>
   <Name>companyLookup</Name>
   <BuilderID>com.bowstreet.builders.webapp.LookupTableBuilder</BuilderID>
   <Inputs>
<Input name = "DataType">XmlData</Input>
<Input name = "VariableType">ValueTagLabelTag</Input>
<Input name = "GetDataFrom">BuilderInput</Input>
<Input name = "TablePosition">InFront</Input>
<Input name = "Name">companyLookup</Input>
<Input name = "XmlData">${MethodCall/companiesGetCompanyList}</Input>
<Input name = "ValueElementName">Value</Input>
<Input name = "LabelElementName">Name</Input>
   </Inputs>
   <ServiceInfo>
<BuilderID>com.bowstreet.builders.webapp.ServiceConsumer2Builder</BuilderID>
<Inputs>
<Input name = "UseAllOperations">true</Input>
<Input name = "OverrideInputs">false</Input>
<Input name = "Name">companies</Input>
<Input name = "ProviderModel">services/CompanyListService</Input>
<Input name = "OperationName">getCompanyList</Input>
</Inputs>
   </ServiceInfo>
</LookupTable>

Input Name	Description
Schema	Select a schema that contains the fields you want to modify. All schemas in the model will be displayed in the select list.
Data Definition Type	The data Definition Type defines the mechanism used to convert schema elements into another format. We can Choose: Read data Definition File - To apply an existing file of conversion properties to the schema. Specify Data Definitions in Builder UI - To manually enter in this Builder's editor individual properties that will be applied to the schema. (Note: The Builder will create a file containing your entries if you so choose. See, "Save Sample Data Definition File" below.)
Data Definition File	This input is available when the Data Definition Type is "Read Data Definition File." Use it to specify an existing XML-based Data Definition File to apply to the schema.
Base Data Definition File	This input is available when you choose "Specify Data Definitions in Builder UI"as the Data Definition Type. (This input is hidden when "Read Data Definition file" is selected as the Data Definition Type above, and the base file is specified within the file.) Use this input if you want the Data Definition File to inherit properties from another (Base) Data Definition File. Select the Data Definition File to be used as the parent Data Definition File from which properties will be inherited. We can set the base in the XML file, directly under the root DataDefinitions element as follows: <BaseDefinitions> <BaseDefinition>/samples/datapage/base_datadef.xml</BaseDefinition> </BaseDefinitions>
Reorder Elements	Enable this check box to reordered fields in the order you specify.
Data Definition Editor
Container Element	Choose the schema Container Element you want to edit. We can choose any schema container schema element that contains "leaf" nodes. In some cases, such as a Domino view or a SQL table, you will have only one choice. In other schemas, such as for SAP, the data might display a number of container elements.
Fields	For each field in the schema, we can specify some or all of the following conversion properties. Label - Alternate text string for display Base Data Definition - Data definition with "BASE" attribute set. Field settings will be inherited from this base definition. Required - Enable to make the field a required field. This field must contain a user entry. Data Type - Select a data type for the field. Enumeration Values - A comma-separated list of choices Hidden - Enable to hide the field. Read Only - Enable to make field a display field. No data can be entered in such a field. Formatting Expression - Select a format for the field from the list of formats. For example, if you choose the format expression DateTimeFormat(FormatString) the string "FormatString" will be replaced with the evaluated version of what the user entered in the Format Expression Argument input before it is passed to the Formatter. Validate Expression - To provide data entry validation of the field, select a validation expression. Choose one of the validate expressions to apply to the field data being submitted. The validate method implements server-side validation and operates on the value returned by the translate method (if translate is used). Note that the following date comparison methods are available to support date validation: Date>today, Date>=today, Date=today, Date<=today, Date<today. Translate Expression - Choose one of the available translate expressions to apply to the field data being submitted. Translating refers to modifying user input for storage as data. For example, a user may insert dashes when entering a Social Security number in a form. A translate method could remove the hyphens from the user input, creating a value that can now be stored as data. Similarly, the "Credit Card 16 digit" expression removes "-" and " " from a string and ignores errors.
Save Sample Data Definition File
Create Data Definition File	This input is available when " Specify data Definitions in Builder UI" is selected as the Data Definition Type. Push this button to create an XML-based Data Definition File that contains the properties you have specified in the Fields editor. You might want to do this to create a reusable library file of the data definitions you've specified. You will be prompted to name the file and provide a save location.
Advanced
Data Definition	This input is available when " Specify data Definitions in Builder UI" is selected as the Data Definition Type. We can use this input to profile data definitions that are not supported or displayed in the Builder's UI.

Property	Description
<Attributes>	Attributes takes an XML value which is the same as the Data Field Modifier Builder takes. A typical Attribute property looks as follows: <Attributes> <Attribute> <Name>color</Name> <Value>black</Value> </Attribute> <Attribute> <Name>size</Name> <Value>${Variables/CurSize}</Value> </Attribute> </Attributes>
<ColumnAlignment>	Takes one of the following values: "left" "right" "center"
<ColumnSorting>	Takes one of the following values: Case Insensitive String, Case Sensitive String, Number, Date, Not Sortable. A typical data definition element using some of the above properties to set column width, alignment, sorting status and style might look as follows: DataDefinitionElement name="DATE_SHIPPED" base="base_SAPDate"> <Label>Date Shipped</Label> <Required>false</Required> <ColumnWidth>400</ColumnWidth> <ColumnAlignment>right</ColumnAlignment> <ColumnSorting>Case Sensitive String</ColumnSorting> <Attributes> <Attribute> <Name>style</Name> <Value>color:red</Value> </Attribute> </Attributes> </DataDefinitionElement>
<ColumnWidth>	Takes a number that represents with width of the column in characters.
<DataEntryControl>	This property associates a Builder ID with a field, when the field is on a data entry page (see Display Control for view-only pages). You can specify both the Builder ID and any builder inputs that are needed. To create XML for the builder inputs, we can use the builder you want in a model, then go to the Model XML view, then copy/paste from the "Inputs" section of the XML. Note that the builder must support an indirect reference input called "Value" in order to be used. For example: <DataEntryControl>com.bowstreet.builders.webapp.TextAreaBuilder</DataEntryControl> <DataEntryInputs> <Inputs> <Input name = "Wrap">off</Input> <Input name = "Cols">80</Input> <Input name = "Rows">5</Input> </Inputs> </DataEntryInputs
<Display Control>	This property is similar to Data Entry Control, but for view-only pages. The corresponding element name for builder inputs is called <DisplayInputs>.
<DisplayMode>	Allowable values are: 0 - DISPLAY_NONE 1 -DISPLAY_AUTO Additional values for container fields include: 2 - DISPLAY_VERTICAL 3 - DISPLAY_HORIZONTAL
<EnumerationValues>	We can use this property to set the choices for a field that has a set of possible values. This property does not provide for separate text/values such as lookup table does. See note below regarding localization of enumeration values. A typical use this property might look as follows: <EnumerationValues> <Value>Shipped</Value> <Value>Out of Stock</Value> <Value>Returned</Value> <Value>In Process</Value> </EnumerationValues>
<FormatterClass>	We can use this property to specify a custom formatter class in a Rich Data Definition file. The formatter class uses the same mechanism and interface as is Data Field Modifier builder. The name of the formatter class is specified with a "FormatterClass" element as shown below. <DataDefinition name="AMOUNT" base="base_Currency"> <Label>Amount</Label> <ColumnSorting>Case Sensitive String</ColumnSorting> <ColumnWidth>100</ColumnWidth> <ColumnAlignment>right</ColumnAlignment> <FormatterClass>com.bowstreet.samples.DashboardFormatter</FormatterClass> </DataDefinition>
<InitialValue>	This can be used to define a default initial value for a field. It is equivalent to setting the "Initial Value" input of the Data Field Modifier Builder.
<LookupTable>	We can use this property to create a lookup table and associate it with a field. To create a new lookup table, specify the Builder s ID, and the Builder must be one that creates a lookup table in the WebApp (Lookup Table, Domino Keyword Lookup, or SAP Help Values). Specify all the required builder inputs in the "Inputs" element as shown below. This example code creates a lookup from XML data using the Lookup Table Builder. This functionality has also been used to automatically create and apply an SAP Help Values lookup. <DataDefinitionElement name="BILLING"> <Label>Billing</Label> <LookupTable> <BuilderID>com.bowstreet.builders.webapp.LookupTableBuilder</BuilderID> <Name>billing</Name> <Inputs> <Input name = "DataType">NewXmlData</Input> <Input name = "GetDataFrom">BuilderInput</Input> <Input name = "TablePosition">InFront</Input> <Input name = "Name">billing</Input> <Input name = "NewXmlData"> <lookup> <entry> <name>Purchase Order</name> <value>1</value> </entry> <entry> <name>Credit Card</name> <value>0</value> </entry> </lookup> </Input> <Input name = "ValueElementName">value</Input> <Input name = "LabelElementName">name</Input> </Inputs> </LookupTable> </DataDefinitionElement> Click here for information about creating a lookup table when calling a Builder that does not automatically place a lookup table in the WebApp
<Properties>	Use this property to set any named property on a DataDefinitionElement. This tag is designed primarily for people making their own Builders, when they want to add new properties to the Data Definition and to access those properties from Builder code. The Properties element looks as follows: <DataDefinition name="AMOUNT"> <Label>Amount</Label> <Properties> <Property name="ColumnWidth">100</Property> <Property name="ColumnAlignment">right</Property> </Properties> </DataDefinition> In this example the name= attribute specifies the property name and the element text contains the property value. Note that the technique illustrated in this example has the identical effect as using the ColumnWidth and ColumnAlignment property tags directly.
<ReadOnly>	Forces a field to be treated as read-only, even when field is displayed with a Data Page that is marked "Data Entry". Effect is equivalent to setting the "Field Behavior" to "View Only" with the Data Field Modifier builder.
<Remove>	Specify a value of "true" to remove a field. The field will not be visible, nor will it be displayed in other Builders such as the Data Column Modifier or Data Field Modifier.