public class DataSourceField
extends java.lang.Object
 This class is not meant to be created and used, it is actually documentation of settings
 allowed in a DataSource descriptor (.ds.xml file), for use with Smart GWT Pro Edition and
 above.
 See com.smartgwt.client.docs.serverds for how to use this documentation.
 
| Modifier and Type | Field and Description | 
|---|---|
| java.lang.Boolean | allowClientRequestedSummariesAffects whether client dsRequests can request summaries for this field. | 
| FieldAuditMode | auditDetermines when the field value should be saved to the audit DataSource when  auditingis enabled. | 
| java.lang.Boolean | autoGeneratedIndicates that values for this field are automatically generated by the database or ORM 
 provider. | 
| java.lang.Boolean | batchUploadCaseSensitiveApplies to the "fetch" operation that is used to look up key values for fields with  importStrategy.displaywhile
 importing data usingBatchUploaderorDataImportserver-side API. | 
| java.lang.String | batchUploadOperationIdUsed to look up key values for fields with  importStrategy.displaywhile
 importing data usingBatchUploaderorDataImportserver-side API. | 
| java.lang.Boolean | canEditControls whether, by default, DataBoundComponents consider this field editable. | 
| java.lang.Boolean | canExportDictates whether the data in this field be exported. | 
| java.lang.Boolean | canFilterShould the user be able to filter data by this field? Affects whether this field will show up
 in dataBoundComponents with UI for filtering data. | 
| java.lang.Boolean | canSaveWhether values in this field can be updated and saved to the dataSource. | 
| boolean | canSortClientOnlyWhen true, this field can only be used for sorting if the data is entirely client-side. | 
| java.lang.Boolean | canViewIf false, this property indicates that this field is considered "server only". | 
| java.lang.Boolean | childrenPropertyIf true, this property indicates that this field will hold an explicit array of child nodes 
 for the current node. | 
| java.lang.String | childTagNameFor a field that is  multiple:"true", controls the name of the XML tag used for each subelement duringDataSource.xmlSerialize(). | 
| java.lang.String | columnCodeSee  DataSource.tableCode. | 
| java.lang.Boolean | creatorOverridesIndicates that normal declarative security rules specified on this field are waived for  rows
 that were created by the current user, as described in the discussion of   dataSource.creatorOverrides. | 
| java.lang.Integer | decimalPadApplies only to fields of type "float" and enforces a minimum number of digits shown after the
 decimal point. | 
| java.lang.Integer | decimalPrecisionApplies only to fields of type "float" and affects how many significant digits are shown. | 
| OperatorId | defaultOperatorThe default search-operator for this field. | 
| java.lang.String | descriptionAn optional description of the DataSourceField's meaning. | 
| boolean | detailWhether this field should be considered a "detail" field by a  DataBoundComponent. | 
| java.lang.String | displayFieldWhen records from this dataSource are displayed in a dataBoundComponent such as a  ListGrid, thedisplayFieldattribute may be used
 to cause some  field to display a value from another field in the record. | 
| DateDisplayFormat | displayFormatThe default date formatter to use for displaying this field. | 
| FormItem | editorTypeSets the default FormItem to be used whenever this field is edited (whether in a grid, form, or
 other component). | 
| VelocityExpression | editRequiresIndicates that the specified  VelocityExpressionmust evaluate
 to true if writes to this field are to be allowed. | 
| java.lang.Boolean | editRequiresAuthenticationWhether a user must be authenticated in order to write to this field. | 
| java.lang.String | editRequiresRoleComma-separated list of user roles that are allowed to write to this field. | 
| HTMLString | emptyDisplayValueText to be used for display by client-side components when this field has a null or  undefined
 value. | 
| java.lang.Boolean | encodeInResponseWhen set for a field with binary data, binary data will be delivered as a Base64 encoded
 string. | 
| java.lang.Boolean | escapeHTMLWhen data values are displayed in DataBound components, by default strings will be interpreted
 as HTML by the browser in most cases. | 
| FormatString | exportFormatAn optional  FormatStringfor this field, for use whenexportingdata to spreadsheet
 formats (XLS and  OOXML/XLSX), XML, JSON or CSV. | 
| java.lang.String | exportTitleOptional different field-title used for exports. | 
| FormItem | filterEditorTypeSets the default FormItem to be used for this field if it appears in a filter row, and  canFilteris not false. | 
| FieldFilterMode | filterOnThis property limits where criteria for this field can be applied. | 
| java.lang.String | fkColumnCodeSee  DataSource.tableCode. | 
| java.lang.String | fkTableCodeSee  DataSource.tableCode. | 
| java.lang.String | foreignDisplayFieldName of another field in a separate dataSource that should be used as the display
  value for this field in the case where a  foreignKeyrelationship
  exists. | 
| java.lang.String | foreignKeyDeclares that this field holds values that can be matched to values from another DataSource
  field, to create a relationship between records from different DataSources or even records
  within the same DataSource. | 
| FormatString | formatFormat string to use when rendering the value in any  DataBoundComponentor when exporting viaDataSource.exportData()orListGrid.exportData()orListGrid.exportClientData(). | 
| GetFieldValueCallback | getFieldValueA  Callback, function, or JavaScript expression used to
 retrieve the field's value from the XML element or JSON record returned from a web service. | 
| java.lang.String | groupFor use in  ComponentSchema, indicates what group to place the
 property in when editing in Reify. | 
| boolean | hiddenWhether this field should be hidden from users by default within a DataBound component. | 
| boolean | ignoreWhether this field should be completely excluded from this dataSource, as if it had never been
 defined. | 
| java.lang.Boolean | ignoreTextMatchStyleNOTE: Only applicable to  clientOnlyDataSources and the built-inSQL,JPAandHibernateDataSources available in Pro, Power
 and  Enterprise versions of Smart GWT. | 
| java.lang.Integer | imageHeightHeight of the image-content of this field. | 
| java.lang.Integer | imageSizeWidth and height of the image-content of this field. | 
| java.lang.Integer | imageWidthWidth of the image-content of this field. | 
| java.lang.Boolean | implicitSequenceFor a field of  type"sequence" on a DataSource withserverType:"sql", this flag
 indicates that the field is  implicitly bound to a sequence. | 
| FieldImportStrategy | importStrategyDeclares the  FieldImportStrategyfor this field. | 
| java.lang.String | importStrategyFailedErrorMessageCustomizable and  localizableerror message to use when
 "displayRequired"importStrategyfails to find corresponding key value. | 
| java.lang.Boolean | inapplicableFor use in  ComponentSchema, a fieldinheritedfrom another schema can be
 redeclared with this property set in order to indicate that the property should not be used. | 
| java.lang.String | includeFromIndicates that this field should be fetched from another, related DataSource. | 
| SummaryFunctionType | includeSummaryFunctionWhen  field.includeFromis
 specified and multiple records
  exist in the related DataSource per record in the including DataSource,includeSummaryFunctionindicates whichSummaryFunctionTypeis used to
  produce the field value. | 
| java.lang.String | includeViaFor a field that uses  includeFrom, specifies whichforeignKeyfield should be
 used to find records in the
  related DataSource. | 
| VelocityExpression | initRequiresIndicates that the specified  VelocityExpressionmust evaluate
 to true if initializations of this field are to be allowed. | 
| java.lang.Boolean | initRequiresAuthenticationWhether a user must be authenticated in order to initialize to this field. | 
| java.lang.String | initRequiresRoleComma-separated list of user roles that are allowed to initialize this field. | 
| java.lang.String | javaClassExplicitly declares the Java class that should be used when data from the client is validated
 by the Smart GWT server and/or applied to Java Beans / POJOs via the server-side API
  com.isomorphic.datasource.DataSource.setProperties(). | 
| java.lang.String | javaCollectionClassSee  javaClass- when
 auto-populating of Java Beans / POJOs based on  inbound DSRequest data, for a field of type
 Collection or Map,javaCollectionClasscan  be used to specify a particular
 concrete class to use. | 
| java.lang.String | javaKeyClassSee  javaClass- when
 auto-populating of Java Beans / POJOs based on  inbound DSRequest data, for a field of Map
 type,javaKeyClasscan be used to specify a particular concrete class for the map
 keys. | 
| JoinType | joinTypeThis property is only applicable to fields of SQL DataSources that also specify a   foreignKeyproperty; it is
 ignored for all other fields. | 
| java.lang.Integer | lengthMaximum number of characters allowed. | 
| java.lang.Boolean | lenientXPathIndicates that getting  valueXPathfor this field should not perform any validation at all and will return null for
 non existing XPaths. | 
| java.lang.Integer | maxFileSizeFor fields of a type that are represented by binary data initially uploaded from a file
 (currently "binary" and "imageFile", see  FieldType), this
 sets the maximum  file size allowed, in bytes. | 
| java.lang.String | mimeTypeFor a  binary field, sets a fixed mime type for
 all files stored to this field. | 
| java.lang.Boolean | multipleIndicates that this field should always be Array-valued. | 
| MultipleFieldStorage | multipleStorageHow values for a  multiple:truefield should be stored. | 
| java.lang.String | multipleStorageSeparatorFor fields that are  multiple:trueand usemultipleStorage, the separator used in the "simpleString"MultipleFieldStoragemode. | 
| java.lang.String | multipleValueSeparatorFor fields that are  multiple:true, the separator used  between values when they are displayed. | 
| FieldName | nameName for this field. | 
| java.lang.Boolean | nillableControls whether an explicit null-valued Record attribute for this field
  should result in  xsi:nilbeing used to transmit the value when serializing
  to XML, like so: | 
| java.lang.String | otherFKsIn addition to regular  foreignKeythis property allows
  defining multiple foreign keys if the field is related to more than one DataSource. | 
| java.lang.Integer | precisionApplies only to fields of type "float" or "integer" and affects how many significant digits are
 shown. | 
| boolean | primaryKeyIndicates either that this field holds a value unique across all records in this
 DataSource, or that it is one of a number of fields marked as primary keys, and the
 combination of the values held in all of those fields is unique across all records in the
 DataSource. | 
| java.lang.Boolean | propertiesOnlyFor use in  ComponentSchemafor fields that contain other
 components, this flag
  suppresses auto-construction for subcomponents that appear under this field. | 
| FormItem | readOnlyEditorTypeSets the default FormItem to be used if this field is marked as   canEdit falseand displayed in an
 editor component such as a DynamicForm. | 
| java.lang.Boolean | recreateOnChangeFor use in  ComponentSchemafor fields that, when changed inReify, should discard the current live component and recreate
 it with the current configured properties. | 
| java.lang.String | relatedTableAliasFor a  SQL DataSourcefield that specifies aforeignKey, this property
 defines the table alias name to use in generated SQL. | 
| boolean | requiredIndicates this field must be non-null in order for a record to pass validation. | 
| java.lang.Object | rootValueFor a field that is a foreignKey establishing a tree relationship, what value indicates a
 root-level node. | 
| java.lang.String | sequenceNameFor a DataSource with  serverType:"sql"with a field of type
  "sequence", the name of the SQL sequence that should be used when inserting new records into
  this table. | 
| java.lang.Boolean | showFileInlineFor a field of type:"imageFile", indicates whether to stream the image and display it inline or
 to display the View and Download icons. | 
| java.lang.String | sortByFieldCauses values for this field to be sorted according to values for another field, for both
 client- and server-side sorting. | 
| java.lang.Boolean | sqlForceInsensitiveThis property is only applicable to fields of SQL DataSources, it overrides default behavior of
  iContainscase insensitive operator on the
 server-side. | 
| java.lang.Boolean | storeMillisecondsFor fields of type "datetime", indicates whether the framework should attempt to preserve
  the millisecond part when persisting to native SQL datetime-type columns. | 
| HashAlgorithm | storeWithHashIf set, causes the field to be securely hashed before saving on an "add" or "update" 
 operation. | 
| java.lang.Boolean | stringInBrowserServer-side setting that causes values for fields of type "integer" or "float" to be
 represented  as Strings when delivered to a web browser, in order to avoid mangling values
 which cannot be represented faithfully in JavaScript. | 
| java.lang.String | titleDefault user-visible title for this field. | 
| FieldType | typeType of this field. | 
| VelocityExpression | updateRequiresIndicates that the specified  VelocityExpressionmust evaluate
 to true if updates to this field are to be allowed. | 
| java.lang.Boolean | updateRequiresAuthenticationWhether a user must be authenticated in order to update to this field. | 
| java.lang.String | updateRequiresRoleComma-separated list of user roles that are allowed to update this field. | 
| java.lang.String | uploadFieldNameUsed by the  BatchUploaderto map a field in an upload file
 to this  dataSourceField. | 
| java.lang.Boolean | useLocalDisplayFieldValueThe  FormItem.useLocalDisplayFieldValueattribute may be specified within a dataSource
 configuration. | 
| Validator[] | validatorsValidators to be applied to this field. | 
| OperatorId[] | validOperatorsSet of search-operators valid for this field. | 
| java.util.Map | valueMapA  com.smartgwt.client.types.ValueMapis a set of legal values for a field. | 
| java.lang.String | valueMapEnumFully qualified Java className of an Enum that should be used to derive this field's  com.smartgwt.client.types.ValueMap. | 
| XPathExpression | valueWriteXPathAlternative XPath expression used to set the field's value. | 
| XPathExpression | valueXPathXPath expression used to retrieve the field's value. | 
| VelocityExpression | viewRequiresIndicates that the specified  VelocityExpressionmust evaluate
 to true if values for the field are to be fetched. | 
| java.lang.Boolean | viewRequiresAuthenticationWhether a user must be authenticated in order to fetch this field. | 
| java.lang.String | viewRequiresRoleComma-separated list of user roles that are allowed to fetch this field. | 
| java.lang.Boolean | xmlAttributeIndicates that  DataSource.xmlSerialize()should serialize this value as an XML attribute. | 
| Constructor and Description | 
|---|
| DataSourceField() | 
public java.lang.Boolean autoGenerated
sequence field, in that
 server-side logic does not expect client code to provide values for the field on "add"
 operations.  However, it is not entirely the same as a sequence:customInsertExpression for a discussion     of thisautoGenerated flag, you have a general ability for field  values to be generated
 by application code (as opposed to being generated by the database or ORM provider).  For
 example, you can use DMI methods,  server scripts, or custom SQL.  (Note,  if you want to have application
 code generate values for primaryKey fields, you may need to use an operationBinding that specifies  providesMissingKeys).
 Default value is null
sequenceName, 
FieldType, 
SequenceModepublic boolean canSortClientOnly
Default value is false
public java.lang.String columnCode
DataSource.tableCode.
 Default value is null
public java.util.Map valueMap
com.smartgwt.client.types.ValueMap is a set of legal values for a field.
  
  The valueMap can be specified as either an Array of legal values, or as an
  Object where each property maps a stored value to a user-displayable value.
  
  To enforce that a field should be constrained to only the values in the valueMap, either
 declare field.type as "enum", or
 use a
 ValidatorType of "isOneOf" with explicitly listed values. 
 Otherwise,
 although a normal SelectItem control will only
 allow values from the valueMap to be
 entered, other controls such as a ComboBox will allow other values 
  to be entered.
  
In XML, a valueMap that specifies only a list of legal values is specified as follows:
    <valueMap>
     <value>Pens & Pencils</value>
     <value>Stationery</value>
     <value>Computer Products</value>
     <value>Furniture</value>
     <value>Misc</value>
    </valueMap>
  
  A ValueMap that specifies stored values mapped to user-visible values is specified as
  follows:
  
    <valueMap>
     <value ID="1">Pens & Pencils</value>
     <value ID="2">Stationery</value>
     <value ID="3">Computer Products</value>
     <value ID="4">Furniture</value>
     <value ID="5">Misc</value>
    </valueMap>
  
 Default value is null
public java.lang.Boolean initRequiresAuthentication
Default value is null
public java.lang.String includeFrom
  The incluedFrom attribute should be of the form
  "dataSourceId.fieldName", for example:
  
     <field includeFrom="supplyItem.itemName"/>
  
  
 A foreignKey declaration
 must exist between the two DataSources, establishing either
  a 1-to-1 relationship or a many-to-1 relationship from this DataSource to the related
  DataSource. The inclusion can be indirect (traverse multiple DataSources) so long as there
  is a chain of foreignKey declarations from the target DataSource to the
  DataSource where the includeFrom field is declared.  You may use dot-notation
  to provide an explicit path between DataSources, or provide the name of only the last
  DataSource in the chain to have the complete path calculated for you at runtime.
  i.e., either of the following are acceptable forms, where foreign keys
  are defined to link records in the current DataSource to Employee records and in turn to
  Office records:
  
    <field includeFrom="Employee.Office.territory"/>
    <!-- OR -->
    <field includeFrom="Office.territory"/>
  
  Note that when using the shorthand form, there is potential ambiguity: there could be
  multiple ways in which two DataSources are related via different intervening DataSources,
  so the auto-discovered relation may be different depending on which other DataSources are
  loaded in the page. For this reason, explicitly spelling out the inclusion path is
  preferred.
  
  Nested inclusions, where an
  included field is itself an included field, are also supported - for details on this and
 other complex scenarios see includeVia docs.
  
 In all cases, name will default
 to the name of the included field,
  or you can specify a different name.
  
If both DataSources are SQLDataSources, HibernateDataSources or JPADataSources (with Hibernate as the provider) the related data will be retrieved via a SQL join and criteria and sort directions applied to the field work normally (they become part of the generated SQL query).
  Note that includeFrom is also supported between two clientOnly or MockDataSources, but not
  for any other combination (for example, a RestDataSource cannot use includeFrom with a
  clientOnly DataSource).  Here, the related data (including any values derived via
 includeSummaryFunction) will be retrieved from cacheData after the
  primary (fetch, add, or update) operation has returned its response.
  
  Otherwise, the related data will be retrieved via performing a DSRequest against
  the related DataSource once the data from the primary DataSource has been retrieved.  In
  this case, criteria or sorting directions applied to the included field are only allowed if
 data paging is not in use (for example ListGrid.dataFetchMode:"basic");
 otherwise,
  criteria and sort direction are ignored for the included field and a warning is logged on
  the server.
  
Editing included fields
 An included field is canEdit:false by default.  Note that 
  included fields are not updatable, even if you set canEdit:true; the server will simply drop
  values for included fields if client code sends them. 
  
  When thinking about editing an included field value, typically what is really intended is to
  edit the value of the foreignKey field.  For example, take the scenario of a
  system that tracks accounts and the employees assigned to manage them.  Given a DataSource
  "account" related one-to-one with DataSource "employee" by a "managerId" foreignKey field,
  we might declare an includeFrom so that the name of the account manager can
  be shown with each "account" record.  
  
Editing the manager's name while viewing the account would be intended to pick a new account manager, and not to change the legal name of the employee who happens to be the current account manager.
  To correctly set up this scenario, declare an includeFrom field that is hidden,
 but is used as the displayField for the foreign key
  field:
  
<field name="managerId" foreignKey="employee.id" displayField="managerName" /> <field name="managerName" includeFrom="employee.name" hidden="true"/>Now:
includeFrom field. Note that when the
  foreignKey and displayField are specified, the 
 framework automatically defaults useLocalDisplayFieldValue to 
  true to ensure the displayed value is picked up from the record being edited.
  optionDataSource
 set to "employees": it will allow
  picking a different "employee" record from the "employee" DataSource.
  editorType="ComboBoxItem" on the
  "managerId" field to allow typeahead search of the "employee" DataSource.
 Note that the foreignDisplayField attribute allows developers to have a different
  fieldName be used locally as a displayField from the field name for the display field
  in the foreign dataSource.
  Including fields that use summary functions
 The Include
 Summary Function feature is used
  for including from a related DataSource where there are multiple related records. It applies
 a SummaryFunctionType to the related records aggregating them
 into single value.
  It is regularly used on directly included fields, but it supports indirect inclusions as well,
 when entire includeFrom+includeSummaryFunction setup is included from
 another DataSource. See includeSummaryFunction docs for more details.
 
Default value is null
public DateDisplayFormat displayFormat
Default value is null
public java.lang.String relatedTableAlias
SQL DataSource field that specifies a
 foreignKey, this property
 defines the table alias name to use in generated SQL.  Aliasing is necessary when the same
 table appears more than once in a query.  This can  happen when using Multiple .  It can also happen when a includeFrom
 \n fields referring to the same related DataSourceforeignKey definition references
 the same dataSource that the field is defined in; this happens with hierarchical structures,
 for example where every Employee reports to another Employee, a so-called "self join", and it
 always requires relatedTableAlias to be specified; failure to do so will
 result in invalid SQL. 
 In case of indirect relationship, when more than single join is
 needed to join the target table, and includeVia is missing, generated
 alias is a concatenation of relatedTableAlias and FK field names starting with the
 first relatedTableAlias  met in chain of relations leading to the target table.
 
 See the "Automatically generated table aliases" section of the SQL Templating for more details.
 
Default value is null
public boolean required
"required"
 validator. 
  
  Note that required should not be set for a server-generated field, such as a
  sequence, or validation will fail on the client.
  
applyWhen condition to
 a required 
  validator introduces subtle complexities to the process of validating an existing record.  
  The client is not guaranteed to know the the full and complete state of the record it is 
 editing because it is common for a DynamicForm to be
 editing a subset of
  fields.  When a field is unconditionally required, things are simple: if the 
 DynamicForm has a FormItem for that field, then
 the required validation
  passes if that FormItem has a value, and fails if it does not.  If the form has no FormItem
  for the field, it can assume that the field has a value because otherwise it would have 
  failed validation when we attempted to add it (when we are adding a record, we of course do 
  know the full and complete state of the record - it is whatever we are about to add).
  When a field is conditionally required, the client can no longer assume that all required fields will have a value. It may be the case that the condition of requirement was not met when the record was added, but now it is. For example, consider these field definitions:
     <field name="yearsAtCurrentAddress" type="integer" />
     <field name="previousAddress" type="text" >
       <validator type="required" errorMessage="Previous address is required if you have been at your current address less than three years">
         <applyWhen operator="and">
           <criteria>
             <criterion fieldName="yearsAtCurrentAddress" operator="lessThan" value="3" />
           </criteria>
         </applyWhen>
       </validator>
     </field>
  
  Imagine a record for this DataSource is added where the user has entered a value of "3" for 
  "yearsAtCurrentAddress", and no previous address.  Later, the value of that field is 
  changed to "2".  If this is done using a form that is also showing the "previousAddress" 
  field, we will know that "previousAddress" has not been provided, so we can fail the 
  validation and the user will get a helpful error message explaining what the problem is.
  
  However, if the form does not also show the "previousAddress" field, we may choose to use an
 OperationBinding that uses outputs to trim the
  record down to just the fields the form does contain, in the interests of avoiding 
  information leakage.  Or perhaps that value is automatically culled from the record before
 the client sees it by the application of a declarative security rule.
  Whatever the reason, if the client does not have the complete record, it is not possible 
  for the client to sensibly apply this validation.  And because the client has no way of 
  knowing if a value is missing because it is genuinely null, or because it has been trimmed
  away by the server, we must treat any null value with suspicion (unless it has a matching 
  FormItem - the presence of the FormItem means that the user can edit the value, so it 
  would make no sense to pair it with a trimmed record that excludes that field value).
  
  When this happens, we mark the validation as having passed on the client, but in need of 
  running on the server.  The server validation makes use of the "storedRecord" facility 
  (look for the description of $storedRecord in the 
 Velocity support overview) to overlay the
 changed record on
  top of the existing record as it currently exists in the database.  This gives the validator
  the complete record including both changed and unchanged values, so it is able to carry 
  out the required check in a meaningful way.  However, you should be aware that the 
  combination of conditional "required" validators and DynamicForms that edit partial 
  records can result in a validation that cannot run on the client and must do both a server 
  roundtrip and a database fetch.
 
Default value is false
Validator.applyWhenpublic java.lang.String sequenceName
serverType:"sql" with a field of type
  "sequence", the name of the SQL sequence that should be used when inserting new records into
  this table.
  Note that this is never required for SQL tables that are generated from Smart GWT DataSources (a default sequence name of tableName + "_" + columnName is chosen, but see the notes below regarding this), and is never required for databases where inserting null into a sequence column is sufficient (MySQL, SQL Server, DB2 and others).
You would only need to set sequenceName if you are integrating with a pre-existing table stored in a database where the sequence must be named for insertion to work (Oracle, Postgres, Firebird) OR you are trying to use the same sequence across multiple DataSources.
  Note: If you specify the sql.{database type}.sequence.name.prefix and/or 
  sql.{database type}.sequence.name.suffix properties in your 
 server.properties file,the generated
 sequence name will include the prefix and/or
  suffix.  For example, with a prefix of "order_system_" and a suffix of "_seq", the sequence
  generated for column "orderNumber" on table "orders" would be:
      order_system_orders_orderNumber_seq
  
 Default value is null
public java.lang.Boolean escapeHTML
If set, this property will be picked up by components bound to this dataSource, notifying them that any HTML characters should be escaped when displaying values for this field.
Default value is null
ListGridField.getEscapeHTML()public java.lang.Boolean updateRequiresAuthentication
Default value is null
public FormatString exportFormat
FormatString for this field, for use when  exporting data to spreadsheet
 formats (XLS and  OOXML/XLSX), XML, JSON or CSV.   You can use this property to override the
 normal format of this field,
 if any, specifically for exports, for both server-based and client-driven exports.   Note,
 for server-driven exports you can specify default formats for date, time and  datetime fields
 by specifying properties export.format.default.date, 
 export.format.default.time and export.format.default.datetime in your
 server.properties file.  Similarly, default formats for float and integer fields
 can be specified with export.format.default.float and 
 export.format.default.integer, respectively.  These formats will be used for
 fields that do not have a "format" or "exportFormat" property specified in the 
 .ds.xml file. 
 Specifically when exporting to spreadsheet formats, the
 FormatString is translated to the type of format string used by spreadsheet
 programs like Excel.  A handful of features are not present in Excel format strings, and some
 features behave slightly differently.  These differences are explained below. 
However, there is no such universal agreement when it come to rounding negative numbers. Some take the view that you should round by taking the number to the larger absolute value, so -7.15 becomes -7.2. Others feel that you should round by taking the number to the larger value in the sense of it being "less negative", so -7.15 becomes -7.1.
Smart GWT formatting takes the first approach and rounds negative numbers away from zero. We do this simply because that is what Java DecimalFormat does. Unfortunately, Excel does the opposite. Therefore, you will see rounding differences on negative numbers on exact 50% boundaries: Smart GWT will format -7.15 as -7.2, while Excel will format the same value as -7.1.
Known differences in behavior in edge cases include:
exportFormat, with the intent of exporting your values in a way that is  similar
 to your application formatting (which would be specified with the  format property), but within the
 confines of what Excel  supports. 
FormatStrings.  If you do hit the limit, the only workaround is to use fewer
 unique FormatStrings. 
You might expect that we would give Excel both the formatted value and the numeric value, but this is only possible by creating what's called a "custom format" for that cell, which as the section above mentions, is limited in that only a few hundred can be created.
 With this
 Excel limitation in mind, it makes sense to just go with the default behavior. If you decide
 otherwise, one option is to use  exportNumbersAsFormattedString, but see the docs for that property for the drawbacks of doing
 this.
 
Default value is null
formatpublic java.lang.String description
OpenAPI specification generated by the framework. 
 Markdown is a commonly used syntax, but you may also embed HTML content in a CDATA tag.
 Default value is null
public java.lang.String title
This will be picked up by DataBound components and other views over this DataSource.
 Note this property frequently does not need to be set
 since DataSource.autoDeriveTitles (on by default) usually picks an appropriate user-visible title if
 you have a reasonable naming convention for your field names. 
 Note that if this field is
 being displayed in a ListGrid bound to this
 dataSource, the ListGridField.headerTitle attribute may be used to specify a different string for display in
 the listGrid column header.
 
Default value is null
public java.lang.String multipleStorageSeparator
multiple:true and use multipleStorage, the separator used in the "simpleString" MultipleFieldStorage mode.  Default value of null means the
 multipleValueSeparator is used instead. 
 NOTE: "simpleString" storage concatenates the
 stringified forms of each of the multiple  values together, delimited with the
 multipleStorageSeparator character(s).  If you use this storage mode with String
 values that themselves contain the  multipleStorageSeparator, they will not be
 correctly retrieved.  To avoid this, use a multi-character delimiter that is not likely to
 occur in regular text, or switch to "json" storage
 
Default value is null
public java.lang.String javaCollectionClass
javaClass - when
 auto-populating of Java Beans / POJOs based on  inbound DSRequest data, for a field of type
 Collection or Map,  javaCollectionClass can  be used to specify a particular
 concrete class to use.  If not specified, and a concrete Collection or Map class cannot be
 discovered using Java Reflection, the following concrete classes are used: java.util.ArrayList is used for fields of type List java.util.HashSet is used for fields of type Set java.util.LinkedList is used for fields of type Queue java.util.LinkedHashMap is used for fields of type Map java.util.ArrayList is used for fields that are otherwise of type
 Collection javaCollectionClass
 to  java.util.LinkedList but your setter method accepts a 
 java.util.ArrayList, you will get a ClassCastException.
 Default value is null
public java.lang.Boolean creatorOverrides
dataSource.creatorOverrides. 
 This setting overrides  dataSource.creatorOverrides, for this field only.  Note
 that field-level creatorOverrides is conceptually slightly different to the
 setting at DataSource and OperationBinding levels.  To give the example of a fetch  operation,
 at the other two levels, it results in a limited set of rows being returned,  rather than a
 security exception being thrown.  At the field-level, it results in values  for individual
 fields being present in those rows, rather than them being stripped out on the server.
 
Default value is null
public FormItem filterEditorType
canFilter is not false.  Note:
 If this is not specified, the edit-formItem type may be derived from the editorType property, or from the
 field's type.
 
Default value is null
public java.lang.String editRequiresRole
OperationBinding.requiresRole for further  details of Smart GWT's declarative role-based
 security. Please see  editRequiresAuthentication [or  viewRequiresAuthentication for viewRequiresRole] for the UI consequences if the user does not
 have the required roles, as well as for information  on customizing field-level security. 
 NOTE: This property prevents both initialization and updates for a field.  If you  have
 a need to prevent just initialization or just updates, you can use initRequiresRole or updateRequiresRole.
 
Default value is null
public java.lang.Boolean batchUploadCaseSensitive
importStrategy.display while
 importing data using BatchUploader or
 DataImport server-side API. Controls whether look up for key values is case
 sensitive or not. Default value is "false".
 Default value is false
public java.lang.Boolean canExport
ListGrid fields.
 Default value is null
public java.lang.Integer imageWidth
ViewFileItem as
 an editor.
 Default value is null
public java.lang.String viewRequiresRole
OperationBinding.requiresRole
 for further details of Smart GWT's declarative  role-based security. Please see  editRequiresAuthentication [or  viewRequiresAuthentication for viewRequiresRole] for the UI consequences if the user does not
 have the required roles, as well as for information  on customizing field-level security.
 Default value is null
public java.lang.Boolean sqlForceInsensitive
iContains case insensitive operator on the
 server-side. Set to true to force case insensitivity by changing case of both
 comparison expression sides or false to rely on database LIKE
 operator directly.SqlSettings for more details
 including database specific defaults and other configuration options.
 Default value is null
SqlSettings overview and related methodspublic java.lang.String mimeType
binary field, sets a fixed mime type for
 all files stored to this field.  Should be set to a standard mime type string, for example,
 "text/plain" for a .txt file. This is useful if a binary field only stored one type of file and you chose not to store filenames, since the extension of the file name is normally used to determine the mime type.
Default value is null
public XPathExpression valueXPath
  This XPath expression will be evaluated in the scope of the record objects selected by 
 the DataSource.recordXPath. 
 For XML data 
 (dataFormat:"xml") this means a
 call to
 XMLTools.selectString() passing the
 selected XML element.  For JSON data
 (dataFormat:"json"), this means
 a call to 
 XMLTools.selectObjects() passing the
 selected JSON object.
  
  In the absence of a valueXPath, for JSON data the value for the field will
  be the value of the same-named property in the record object selected by
  recordXPath.  
  
For XML data, the value will be the attribute or subelement named after the field name. For example, for a field "author" on a record element <book>, the following structures require no valueXPath:
     <book author="Mark Jones"/>
 
     <book>
         <author>Mark Jones</author>
     </book>
  
  
  If valueXPath is not required for your field because of the default handling
  described above, don't specify it, as it's slightly slower.
  
To learn about XPath, try the following search: http://www.google.com/search?q=xpath+tutorial
Using valueXPath with the Smart GWT server
  If you're using the Smart GWT server to return data via the DSResponse object (or
  indirectly doing so using DataSource DMI), the valueXPath you specify on the DataSource
  fields will be applied to the data you return via the 
  JXPath library.
  See also the server side Java APIs DataSource.setProperties() and 
  DSResponse.setData().
  
  If you are returning Java Beans as your DSResponse data, normally each dataSource field
  receives the value of the same-named Java Bean property, that is, a field "zipCode" is
  populated by looking for "getZipCode()" on the objects passed as DSResponse data.  You can
  use valueXPath to retrieve properties from subobjects, so long as a chain of
  getter methods exists that corresponds to the valueXPath.  For example, a valueXPath of
  "address/zipCode" expects to call "getAddress()" on the bean(s) passed to
  DSResponse.setData(), followed by "getZipCode()" on whatever object "getAddress()" returns.
  
When you are saving data, the inbound DSRequest values, available as a Java Map, will use just dataSource field names as Map keys, not the valueXPath used to derive them. However, to achieve bidirectional valueXPath binding, you can use the server-side method dataSource.setProperties() to use the valueXPath when setting properties on your server object model. When applied as a setter, an XPath like "address/zipCode" attempts "getAddress()" followed by "setZipCode()" on the returned object. JXPath also has some ability to auto-create intervening objects if they are missing, such as auto-creating an "address" subobject when applying "address/zipCode" as a valueXPath.
See the JXPath library documentation for complete details, including other types of server object models supported, such as server-side XML.
Default value is null
public VelocityExpression initRequires
VelocityExpression must evaluate
 to true if initializations of this field are to be allowed.  If the specified expression does
 not  evaluate to true, the field will be removed from the request as described for  editRequiresAuthentication.  In addition to the normal context variables available to
 Velocity expressions in Smart GWT, expressions you write for field-level requires
 clauses - initRequires,  viewRequires, editRequires and  updateRequires - can
 reference two additional variables:  $fieldName and $dsName.  These
 are the names of the dataSource and  field currently undergoing requires checks. 
 They are helpful because they allow you to write a generic checker function that can be used to
 handle requires checks for multiple fields and dataSources. 
 NOTE: This
 property only prevents initialization of a field; updates will still be  allowed.  You should
 only use this property if you have a special requirement; ordinarily, use editRequires, which applies
 security for both types of write.
 
Default value is null
public java.lang.String sortByField
 This can be used to establish a sort order for a field
 that is not the normal sorting order indicated by the field value, typically by having the
 sortByField as a hidden field.   
 If using SQLDataSource, consider using a customSelectExpression as
 an efficient way to populate the sortByField with the results of a SQL expression.
 
Default value is null
public java.lang.Boolean storeMilliseconds
 Other than the two cases just mentioned which are known to fail, storeMilliseconds
 
  has been tested and is officially supported with the following products and minimum 
  versions:
sqlStorageStrategy to store a datetime 
  value with sub-second precision in any database - see below.
  
  When the system generates SQL to insert or update datetime values including a millisecond
  element, it does so using a database-specific format string specified in property 
  defaultDateTimeFormatWithMilliseconds in your server.properties 
  file.  These format strings should conform to the rules of the
  
  Java SimpleDateFormat class.  Suitable format strings are provided for all default 
  databases out of the box; if you need to override one or provide a new one, you do so as
  shown in this example:
    sql.MyNewDatabase.defaultDateTimeFormatWithMilliseconds: yy-MM-dd'T'hh.mm.ss.SSS
  
  Note that this property only controls the persistence of milliseconds into the database;
  there is no built-in support for sub-second elements of datetimes in any Smart GWT visual
 components.  See also the documentation for DataSource.trimMilliseconds for
 more 
  details of how sub-second datetime elements are handled in the client-server flow.
  
 This property is only applicable to DataSources of serverType 
 "sql" and fields of type "datetime".  It is ignored
 in all other 
  cases.  However, note that the built-in JPA and Hibernate dataSources will always persist
  millisecond values automatically if the underlying Java type, database and column support
  it.
  
  Finally, note that this property only has an effect on native datetime-type fields.
 When you use sqlStorageStrategy to store a temporal value in a 
 text or number column, it is the sqlDateFormat you use that dictates 
  the precision.  For example, a field with sqlStorageStrategy:"text" and 
  sqlDateFormat:"yyyy-MM-dd hh:mm:ss.SSS" would store and retrieve with millisecond
  precsion; the same field with sqlDateFormat:"yyyy-MM-dd hh:mm" would store
  and retrieve with precision to the nearest minute only.
 
Default value is null
DataSource.trimMillisecondspublic java.lang.Boolean canEdit
false to draw this field read-only.    For a field that should never be changed
 from the UI, consider using canSave instead, which will both mark a field as non-editable and reject any attempt to
 programmatically change the value on the server (when using the Smart GWT Server). 
 This
 attribute may not effect all dataBoundComponents - the  DataBoundComponent.canEditFieldAttribute may be set at the component level to look for a
 different attribute on the dataSourceField, and components allow developers to explicitly
 override this default (see ListGridField.canEdit. FormItem.canEdit for example).
 
Default value is null
public java.lang.Boolean showFileInline
Default value is null
public java.lang.String javaKeyClass
javaClass - when
 auto-populating of Java Beans / POJOs based on  inbound DSRequest data, for a field of Map
 type, javaKeyClass can be used to specify a particular concrete class for the map
 keys.  If not specified, and a concrete type cannot be discovered using Java Reflection,
 java.lang.Object is used. Note that javaKeyClass take precedence over
 generics if both are used.
 Default value is null
public java.lang.String fkColumnCode
DataSource.tableCode.
 Default value is null
public java.lang.Boolean recreateOnChange
ComponentSchema for fields that, when changed in
 Reify, should discard the current live component and recreate
 it with the current configured properties. This property is typically set when a custom component is being used that doesn't have a setter for the field.
Default value is null
public java.lang.String childTagName
multiple:"true", controls the name of the XML tag used for each subelement during DataSource.xmlSerialize().  If unset, the
 default tag name is "value" for a field of simple type, and for a field of DataSource type, is
 the tagName or ID of the DataSource (as though xmlSerialize() were called on the
 child DataSource).
 
Default value is null
public java.lang.Boolean canView
dataBoundComponent, it will
 be droppedcanEdit, no updates     to the field
 are allowed from the client.  If you explicitly add a value for the field      to, eg, a record
 you are passing to DataSource.updateData(), the server will strip     the value out of the record before
 processing the update request. canView:false is not the same thing as
 hidden.  Use 
 canView:false when you want to prevent the client from ever seeing a field's 
 definition or values; use hidden:true if it is fine from a security perspective
 that a field's definition and values are sent to the browser, but the field should not by
 default appear in user interface elements (but could do in some cases, like a special screen
 for advanced users or administrators, for example). Note that this property must be set explicitly to false to have an effect; a null or undefined setting is treated the same as true.
 This property is used to implement field-level view security: failing a  viewRequiresAuthentication,  viewRequiresRole or viewRequires test is 
 equivalent to setting canView:false on the field (and, indeed, from the  client's
 perspective, the field has had canView:false set).
 
Default value is null
public java.lang.Boolean viewRequiresAuthentication
 The way this behavior works is to remove the field from the expressed or
 implied list of fields to return (note, this means the field is removed from the list of fields
 returned  in data records; the actual field definition in the dataSource is still
 returned, but in a stripped-down state, as described below).   A list of fields can be
 expressed using OperationBinding.outputs or DSRequest.outputs; in the absence of those, the entire set of fields defined in  the
 DataSource is implied.  You can override this behavior on a per-request basis by  providing a
 DMI that just re-adds the names of the fields you want for that particular  request to the
 "consolidated outputs".  See the server-side Javadoc for 
 DSRequest.getConsolidatedOutputs(). 
 In addition to this behavior of trimming
 off values in fetched records, a field that fails a field-level security check (either this one
 or one of the two more specific checks,  viewRequiresRole and viewRequires) will be  altered
 in the version of the dataSource returned to the client by the  <loadDS>
 JSP tag or  DataSourceLoader servlet.
 
canView:false, and
 thus effectively be inert and unusable on the clienthidden.  By default,
 this means that DataBoundComponents will not show the
 field, though this can be overridden for  individual components.  If you do choose to unhide
 the field, bear in mind that it will  never actually show any data, because the underlying
 security test has still failedviewRequiresAuthentication on a field  implies editRequiresAuthenticationDefault value is null
public java.lang.String foreignKey
  The format of foreignKey is
  dataSourceId.fieldName.
  
  For a foreignKey within the same dataSource, you can omit the dataSourceId
  and just specify fieldName.  For example, to create a tree relationship
  within a DataSource:
  
  
  
       DataSource supplyItem = new DataSource();
       DataSourceField itemId = new DataSourceField();
       itemId.setType(FieldType.SEQUENCE);
       itemId.setPrimaryKey(true);
       DataSourceField parentId = new DataSourceField();
       parentId.setType(FieldType.INTEGER);
       parentId.setForeignKey("itemId");
       supplyItem.setFields(itemId, parentId);
  
  
  
  foreignKey declarations also allow other automatic behaviors by
 DataBoundComponents, such as ListGrid.fetchRelatedData().
  
  For SQLDataSources foreign keys can be automatically discovered from SQL tables if
  autoDeriveSchema is set.
 
Default value is false
public OperatorId[] validOperators
If not specified, all operators that are valid for the field type are allowed.
Default value is null
public boolean hidden
 See detail for fields that should be
 hidden in a summary view such as a ListGrid, but still
 available to the user. 
 NOTE: This property is not a security setting - data
 for hidden fields is  still delivered to the client, it just isn't shown to the user.  If you
 wish to make sure  that only appropriate data reaches the client, use OperationBinding.outputs, canView:false on the field, or a
 field-level declarative security setting like  viewRequiresRole.
 
Default value is false
public java.lang.Boolean inapplicable
ComponentSchema, a field inherited from another schema can be
 redeclared with this property set in order to indicate that the property should not be used.
  This is primarily used to influence Reify.  For
 simple type properties, this avoids the property appearing in the Component Editor.   
 For
 fields that hold subcomponents, this prevents inappropriate drag and drop.  For example, a
 custom class called MyDialog may automatically create a series of children, and
 not allow arbitrary other children to be added.  In this case, the inherited property Canvas.children should be marked inapplicable
 in order to prevent arbitrary components being dropped onto a MyDialog instance.
 
Default value is null
public java.lang.Integer decimalPrecision
For example, with decimalPrecision 3, if the field value is 343.672677, 343.673 is shown.
 If the value is 125.2, 125.2 is shown - decimalPrecision will not cause extra zeros to be
 added.  Use decimalPad for
 this. 
A number is always shown with its original precision when edited.
Default value is null
Appearance overview and related methodspublic boolean primaryKey
primaryKey field per DataSource, and  ideally
 this field should be of type
 "sequence".  If you have control of the underlying tables, there is nothing to stop you from
 adding a field like  this (a so-called "synthetic" or "surrogate" key), even for tables that
 already have a set of columns that could combine to make a composite key (a so-called "natural"
 key).  Also,   it is neither necessary nor correct to use a composite primaryKey because you
 want to  enforce uniqueness across that combination of fields.  You can achieve that by
 declaring a unique constraint in the table schema, or use an isUnique  validator with
 validator.criteriaFields, or both; there is no need to use a  composite key to
 enforce uniqueness  Note that composite primaryKeys are not supported in tree-structured
 datasets  (Tree and ResultTree) or components (TreeGrid,  ColumnTree).  Tree-structured data requires that nodes have a
 unique  idField, with the parent/child
 relationship expressed through the  parentIdField.  This implies that
 binding a Tree to a DataSource requires that the DataSource have a singular primaryKey, and
 that the primaryKey field is  also the idField, as described in the tree databinding overview 
 A DataSource that can
 only perform the "fetch" operation does not require a primaryKey unless it contains
 binary fields.  If a DataSource  allows
 modification of DataSource records through add, update and remove DataSource  operations, or it
 contains one or more binary fields, one or more fields must be marked as  the primary key. 
Smart GWT requires a primary key value to uniquely identify records when communicating updates or deletions to the server. There is no requirement that the primaryKey field be mapped to an actual "primary key" in your object model, web service, or database (though this is the most obvious and natural thing to do, of course). The only requirement is that the combined values of the primaryKey fields be unique for a given browser instance for the lifetime of the page.
 If using Smart GWT's SQL engine and
 generating SQL tables using the Database
 Configuration Tool, the table column generated from a primaryKey field will have a unique
 constraint applied in the database table and, if the field is of type "sequence", the database
 column will also be created as an "identity column" in those databases that implement
 sequence-type handling with identity columns.
 
Default value is false
public java.lang.Boolean allowClientRequestedSummaries
 Default setting of
 null means that the DataSource-wide default setting DataSource.allowClientRequestedSummaries is used for this field.
 
Default value is null
public VelocityExpression updateRequires
VelocityExpression must evaluate
 to true if updates to this field are to be allowed.  If the specified expression does not 
 evaluate to true, the field will be removed from the request as described for  editRequiresAuthentication.  In addition to the normal context variables available to
 Velocity expressions in Smart GWT, expressions you write for field-level requires
 clauses - updateRequires,  viewRequires, editRequires and  initRequires - can reference
 two additional variables:  $fieldName and $dsName.  These are the
 names of the dataSource and  field currently undergoing requires checks.  They are
 helpful because they allow you to write a generic checker function that can be used to handle
 requires checks for multiple fields and dataSources. 
 NOTE: This
 property only prevents update of a field; initialization will still be  allowed.  You should
 only use this property if you have a special requirement; ordinarily, use editRequires, which applies
 security for both types of write.
 
Default value is null
public Validator[] validators
Validators are applied whenever there is an attempt to save changes to a field.
 For the available set of built-in validators, and how to define
 a custom validator, see the Validator class.
 
Default value is null
Validator, 
Validation overview and related methodspublic FormItem editorType
 If unset, a FormItem will be automatically chosen based on the type of
 the field, by the rules explained here.
 
Default value is null
public java.lang.Boolean xmlAttribute
DataSource.xmlSerialize() should serialize this value as an XML attribute. Note this does not need to be declared in order for DataSource records to be derived from XML data: a field will be populated with either an attribute or subelement with matching name.
Default value is null
public java.lang.String initRequiresRole
 NOTE: This property only prevents initialization of a field; updates
 will still be  allowed.  You should only use this property if you have a special requirement;
 ordinarily, use editRequiresRole, which applies security for both types of write.
 
Default value is null
public java.lang.String importStrategyFailedErrorMessage
localizable error message to use when
 "displayRequired" importStrategy fails to find corresponding key value. Default message: Key mapping for
 display value is required, but was not found.
 Default value is null
importStrategypublic java.lang.Integer length
length range validator will be
 automatically generated on both the client and server side to enforce this maximum length
 (unless such a validator is explicitly present for the field already).  The TextItem.enforceLength
 attribute can also  explicitly limit user input for freeform text items editing fields with an
 explicit length specified. 
 NOTE: For DataSources of type "sql", this property has a
 bearing on the type of  column we use when the underlying table is created by a DataSource 
 import in the Admin Console.  Below  a certain length (which is
 database-specific, see below), we use standard VARCHAR columns; above that length,
 we use an alternate strategy (again, database-specific).  For  these long fields, we sometimes
 also generate different SQL for "update" and "add"  operations, using JDBC "?" replacement
 parameters rather than embedding values directly in  the generated SQL; whether or not this is
 done depends entirely on what the underlying  database product and/or JDBC driver will allow.
 
 Table of field length limits for supported databases:
| Database product | VARCHAR limit * | Type used above limit | 
| HSQLDB | None | - | 
| IBM DB2 | 4000 | CLOB | 
| Firebird | 32767 | BLOB with subtype 1 | 
| Informix | 255 / 32739 | LVARCHAR / TEXT ** | 
| Microsoft SQL Server | 8000 | TEXT | 
| MySQL | 255 / 65535 / 16M | TEXT / MEDIUMTEXT / LONGTEXT *** | 
| MariaDB | 255 / 65535 / 16M | TEXT / MEDIUMTEXT / LONGTEXT *** | 
| Oracle | 4000 | CLOB | 
| PostgreSQL | 4000 | TEXT | 
** Informix has a limit of just 255 characters for VARCHAR, but has a native LVARCHAR type which supports nearly 32K characters without needing to fall back on long datatypes. Therefore, with that one product, we have two thresholds for a change in storage type.
*** MySQL has a limit of 255 characters for VARCHAR, 65,535 characters for TEXT and 16,777,215 for MEDIUMTEXT; therefore, with that one product, we have three thresholds for a change in storage type.
Default value is null
ListGridField.getWidth()public java.lang.String valueMapEnum
com.smartgwt.client.types.ValueMap.  This has the same behavior of auto-deriving a
 valueMap from a Java Enum as DataSource.autoDeriveSchema
 except it applies only to one field. 
 If you enable autoDeriveSchema there is
 no need to set valueMapEnum for Enum fields unless you want to actually
 override the behavior to use a different Enum for the field (eg, a superclass Enum that
 is more restrictive).
 
Default value is null
public FormItem readOnlyEditorType
canEdit false and displayed in an
 editor component such as a DynamicForm.  This property may also be specified at the type
 level by specifying  SimpleType.readOnlyEditorType.
 
Default value is null
public boolean ignore
If set to true, the field will be entirely omitted when serving a DataSource derived from a server-side definition (typically a .ds.xml file) to the client.
Default value is false
public java.lang.Boolean canSave
 If set to
 false, this field will default to being non-editable in standard editing
 components (DynamicForm, editable ListGrid), but will be editable when displayed for filtering
 purposes only (in a SearchForm or ListGrid\n filter editor.  If
 canEdit is explicitly
 specified it will take  precedence over this client-side behavior, but the server will still
 enforce the no-save policy (described below). 
 NOTE: If you are using Smart GWT Server and
 have specified canSave: false  for a field in a DataSource definition
 (.ds.xml file), this is enforced on  the server.  This means that we will strip
 out any attempt to set the value of such a  field before trying to process any update or add
 request, similar to what happens when  a field-level
 declarative security check fails.
 
Default value is null
public java.lang.Boolean editRequiresAuthentication
 This property affects two things.  Firstly, the server determines when the
 DataSource is  first loaded if we have an authenticated user; if we don't, the field is marked 
 canEdit: false.  Secondly, when an insert or update request is received from  the
 client, the server removes the field from the values clause before the request is
 processed. 
 Note that you can override this behavior.  The canEdit setting can
 be overridden  on the the client-side DataSource like any other client-side property.  The
 value-removing  behavior can be overridden on a per-request basis by providing a DMI that
 re-adds values for the fields you want for that particular request to the values object (the
 values originally  sent up by the client are available on the DSRequest).  See the server-side
 Javadocs for  DSRequest.getValues() and
 DSRequest.getClientSuppliedValues().
 
Default value is null
public HTMLString emptyDisplayValue
Default value is null
public java.lang.Integer maxFileSize
FieldType), this
 sets the maximum  file size allowed, in bytes.
 Default value is null
com.smartgwt.client.data.DataSource#maxFileSizeExceededMessagepublic GetFieldValueCallback getFieldValue
Callback, function, or JavaScript expression used to
 retrieve the field's value from the XML element or JSON record returned from a web service. 
 This is an advanced attribute for use when a valueXPath setting is
 insufficient to derive a field's value, yet an implementation of DataSource.transformResponse() is
 overkill. 
For the required parameters, see the documentation for GetFieldValueCallback.
Default value is null
public java.lang.Boolean useLocalDisplayFieldValue
FormItem.useLocalDisplayFieldValue attribute may be specified within a dataSource
 configuration.  This property governs whether, when displaying a record in an editor
 component, the displayField value for this field should be picked up directly from
 the record value (as opposed to being retrieved via an explicit fetch operation against the
 FormItem.optionDataSource). See FormItem.useLocalDisplayFieldValue for further details. 
 If not explicitly set, dataSources
 backed by the  Smart GWT server will set
 this property to true automatically for fields where the specified displayField values are
 retrieved from another dataSource using the includeFrom  feature.
 
Default value is null
public FieldName name
 Must be unique across all fields within the DataSource as well as a
 valid JavaScript identifier - see FieldName for details and
 how to check for validity. 
The field name is also the property in each DataSource record which holds the value for this field.
Default value is null
Basics overview and related methodspublic java.lang.Object rootValue
 Note that the rootValue may be overridden on a specific
 ResultTree instance by setting ResultTree.rootNode, or if the ResultTree is auto-generated by a TreeGrid, by setting TreeGrid.treeRootValue. This allows
 a component to navigate a subtree of the hierarchical data from this dataSource starting at a
 particular node.
 
Default value is null
public HashAlgorithm storeWithHash
Default value is null
public FieldAuditMode audit
auditing is enabled.  Setting the property
 to "change" will conserve storage by only saving out the value when it's changed, and setting
 it to "never" will exclude the field values from ever being saved during auditing. audit setting is "change"_filename,
 _filesize and _date_created metadata fields inherit their
 audit setting from the associated binary field, if no explicit setting is provided
 for the metadata field.  This includes inheriting the  the implicit "change" default.  See the
 binary fields overview  for more details about
 the binary metadata fields, including how to provide explicit  properties for them_filename and _filesize metadata values.  If both those values are
 unchanged, we assume the content is also unchanged.  If you want to compare the actual  binary
 content instead, set DataSource property  DataSource.compareMetadataForAuditChangeStatus to false, but bear in mind this may have
 performance implications, as described in the documentation for that propertyDefault value is "always"
public XPathExpression valueWriteXPath
 If is not set, then dataSourceField.valueXPath is
 used, see its description for details. 
 See also Smart GWT server java APIs
 DataSource.setProperties() and DSResponse.setData().
 
Default value is null
public java.lang.String includeVia
includeFrom, specifies which
 foreignKey field should be
 used to find records in the
  related DataSource.
  
  includeVia only needs to be set when you have more than one
  foreignKey to the same related DataSource.  If you have multiple
  foreignKeys to multiple different DataSources, there is no need to set
  includeVia.
  
For example, perhaps you have a DataSource "moneyTransfer" where each record represents a money transfer, where the source and payment currencies are different, and the list of currencies is stored in a related DataSource "currency". Each "moneyTransfer" record is linked to 2 "currency" records, through two different foreignKey fields, "sourceCurrencyId" and "paymentCurrencyId".
  The following declarations would be required to use includeFrom to get a
  include the field "currencySymbol" from each of the two related "currency" records.
  
    <field name="sourceCurrencyId" foreignKey="currency.id"/>
    <field name="paymentCurrencyId" foreignKey="currency.id"/>
    <field name="sourceCurrencySymbol" includeFrom="currency.currencySymbol" includeVia="sourceCurrencyId"/>
    <field name="paymentCurrencySymbol" includeFrom="currency.currencySymbol" includeVia="paymentCurrencyId"/>
  
  
includeVia
 The includeVia feature uses SQL table aliases in the generated SQL when generating
 multiple SQL joins
 to the same SQL table.  When using SQL
 Templating, it's sometimes necessary to know 
  the names of the aliases in the generated SQL.  The table alias used can be configured via
 setting relatedTableAlias on the foreignKey field, for
  example, using the declarations below, aliases "source" and "payment" would be used for the
  two "currency" tables.
  
    <field name="sourceCurrencyId" foreignKey="currency.id" relatedTableAlias="source"/>
    <field name="paymentCurrencyId" foreignKey="currency.id" relatedTableAlias="payment"/>
    <field name="sourceCurrencySymbol" includeFrom="currency.currencySymbol" includeVia="sourceCurrencyId"/>
    <field name="paymentCurrencySymbol" includeFrom="currency.currencySymbol" includeVia="paymentCurrencyId"/>
  
  
relatedTableAlias
 General rule is that if relatedTableAlias is present it is used as alias or its
 segment, otherwise
 foreignKey field name linked by includeVia is used instead. See the
 "Automatically
 generated table aliases" section of the SQL
 Templating for the complete set of
  general rules how aliases are generated. Also, see some samples below.
  
 Sometimes you may have two includeFrom fields that include a field which is itself
 included from 
  another DataSource, for example:
  
    <field name="sourceCurId" nativeName="sourceCurrencyId" foreignKey="currency.id" relatedTableAlias="source"/>
    <field name="sourceCurrencySymbol" includeFrom="currency.currencySymbol" includeVia="sourceCurId"/>
    <field name="sourceCurrencyGroup" includeFrom="currency.groupName" includeVia="sourceCurId"/>
    <field name="paymentCurId" nativeName="paymentCurrencyId" foreignKey="currency.id" relatedTableAlias="payment"/>
    <field name="paymentCurrencySymbol" includeFrom="currency.currencySymbol" includeVia="paymentCurId"/>
    <field name="paymentCurrencyGroup" includeFrom="currency.groupName" includeVia="paymentCurId"/>
  
 .. where the "currency" DataSource used above is related to the "currencyGroup" DataSource via
 fields:
  
    <field name="groupId" type="integer" foreignKey="currencyGroup.id" relatedTableAlias="group"/>
    <field name="groupName" type="text" includeFrom="currencyGroup.groupName"/>
  
 Fields "sourceCurrencyGroup" and "paymentCurrencyGroup" include a field that is itself an
 included field.
 In this case "currencyGroup" table will be referenced two times, and its
 relatedTableAlias defined in 
 "currency" DataSource will be prefixed with the referenced by includeVia field's
 relatedTableAlias
  value to make aliases unique in generated SQL: "source_group" and "payment_group".
  The same aliases would be used if "sourceCurrencyGroup" and "paymentCurrencyGroup" fields were to include "currencyGroup.groupName" indirectly:
    <field name="sourceCurrencyGroup" includeFrom="currency.currencyGroup.groupName" includeVia="sourceCurId"/>
    <field name="paymentCurrencyGroup" includeFrom="currency.currencyGroup.groupName" includeVia="paymentCurId"/>
  
  This works the same for more complex relationships. If we add a "moneyTransferDetail" DataSource to the sample above which has multiple references to "moneyTransfer" DataSource and would include fields from "currency" and "currencyGroup" DataSources:
    <field name="mtId" nativeName="moneyTransferId" type="integer" foreignKey="moneyTransfer.id" relatedTableAlias="main" />
    <field name="mainTransferName" includeFrom="moneyTransfer.name" includeVia="mtId" />
    <field name="mainSourceSymbol" includeFrom="moneyTransfer.sourceCurrencySymbol" includeVia="mtId" />
    <field name="mainSourceGroup" includeFrom="moneyTransfer.sourceCurrencyGroup" includeVia="mtId" />
    <field name="mainPaymentSymbol" includeFrom="moneyTransfer.paymentCurrencySymbol" includeVia="mtId" />
    <field name="mainPaymentGroup" includeFrom="moneyTransfer.paymentCurrencyGroup" includeVia="mtId" />
    <field name="mtPrevId" nativeName="moneyTransferPreviousId" type="integer" foreignKey="moneyTransfer.id" relatedTableAlias="prev" />
    <field name="previousTransferName" includeFrom="moneyTransfer.name" includeVia="mtPrevId" />
    <field name="previousSourceSymbol" includeFrom="moneyTransfer.sourceCurrencySymbol" includeVia="mtPrevId" />
    <field name="previousSourceGroup" includeFrom="moneyTransfer.sourceCurrencyGroup" includeVia="mtPrevId" />
    <field name="previousPaymentSymbol" includeFrom="moneyTransfer.paymentCurrencySymbol" includeVia="mtPrevId" />
    <field name="previousPaymentGroup" includeFrom="moneyTransfer.paymentCurrencyGroup" includeVia="mtPrevId" />
  
  In this scenario the "currencyGroup" table will be joined 4 times - for all main/prev transfer
  and payment/source currency combinations.  So, aliases will be prefixed with both
  intermediate relatedTableAlias values: "main_source_group",
  "main_payment_group", "prev_source_group", "prev_payment_group".
  
  It is also allowed to specify a series of FK fields in includeVia, for example
  "moneyTransferDetail" could declare:
  
    <field name="mainSourceCurrencyGroup" includeFrom="moneyTransfer.currency.currencyGroup.groupName" includeVia="mtId.sourceCurId"/>
    <field name="mainPaymentCurrencyGroup" includeFrom="moneyTransfer.currency.currencyGroup.groupName" includeVia="mtId.paymentCurId"/>
  
 In this case the prefix used for table aliases will be the same, cause relations referenced in
 includeVia
  are the same as in previous example: "main_source_group" and "main_payment_group".
  
 Note that if related table alias are completely missing then, according to general rule,
 foreignKey field names will be used in aliases: "mtId_sourceCurId_groupId" and
 "mtId_paymentCurId_groupId".
 
Default value is null
public java.lang.Boolean stringInBrowser
JavaScript has a single "Number" type which internally stores numbers in a format equivalent to Java's "Double" - double-precision floating point. This means it cannot represent the full range of Java's Long type: Java Longs can represent integral values between -2^63 to 2^63-1, whereas JavaScript Number can only represent exact integer values between -2^53 and 2^53. Similarly, JavaScript's Number type cannot represent Java's unlimited-size BigInteger or unlimited-precision BigDecimal objects at all.
 The stringInBrowser setting can be used to deliver numeric values as
 Strings to the browser.  This is intended to allow read-only display and successful
 round-tripping of the numeric value, however, it will not cause number-oriented features such
 as SpinnerItem, Slider, ListGrid summaries or
 range-checking validators or criteria to actually work. 
 If
 stringInBrowser is not set, the default behavior is configured by the 
 server.properties setting datasource.defaultStringInBrowser.  If 
 this flag is false, numeric values are delivered to the client as numbers, even where  this
 will lead  to a loss of precision.  If the flag is true (which is the the default), the
 behavior is to prevent range overflow for numeric values: 
DMI methods are called.  This default set of
 behaviors is intended to automatically deal with cases like numeric primaryKey or foreignKey values that are never
 used as numbers, but happen to use the full Java Long range.  To disable the above behaviors,
 set stringInBrowser="false". 
 If stringInBrowser is explicitly set
 to true: 
operators that check if values are in a particular      range will always pass canFilter:false were set, to avoid showing      non-functional search interfaces to the user. 
 Set canFilter="true" to avoid      this effect  This setting is
 recommended for presenting out-of-range issues or precision loss on fields that represent
 actual quantities (as opposed to primaryKey or foreignKey fields, which really represent IDs). 
 To ensure unlimited-precision BigDecimal values are preserved, you should also set javaClass. 
 Note that responses
 delivered as JSON or XML, such as responses from the RESTHandler servlet, are not affected.  This setting
 applies only to responses delivered to a web browser. 
 The entirety of stringInBrowser
 processing can be completely disabled by setting  server.properties flag
 datasource.disableStringInBrowser to true. This will cause all numeric values to
 be delivered as numbers without even attempting to  detect if this will lead to a loss of
 precision.  This setting overrides both the  stringInBrowser field setting and the
 datasource.defaultStringInBrowser server.properties flag. 
 stringInBrowser and client-side DataSources 
For DataSources that are not based on the Smart GWT Server, the client-side behaviors described above (such as leaving user input in string form if precision would be lost) are active by default.
 In addition,
 if dataSource.dataFormat:"xml"
 is used, values that would lose precision remain as strings.  For JSON, if behavior similar to
 stringInBrowser is desired, your server response must send the values as JSON
 strings rather than JSON numeric literals. 
 You can use defaultStringInBrowser to disable
 these behaviors.  NOTE: don't use this setting if you are using the Smart GWT Server,
 use the server.properties approach described above instead.
 
Default value is null
public JoinType joinType
foreignKey property; it is
 ignored for all other fields.  Indicates the  type of join to make between the tables
 underlying this DataSource and the other DataSource referred to in the foreignKey
 property, when resolving includeFrom  fields.  The default value of null is the same as specifying "inner".  Note,
 outer joins are allowed for all supported database products only if you are using  ANSI-style joins, which is not the
 case by default.  If you are using the older strategy of additional join expressions in the
 WHERE clause, outer  joins are only supported for database products that provide a proprietary
 native syntax for  expressing outer joins.  Those products are:
Default value is null
public java.lang.String group
ComponentSchema, indicates what group to place the
 property in when editing in Reify.
 Default value is null
public java.lang.Boolean canFilter
 Note that setting
 canFilter:false only affects UI and is not a security feature.  Enforcing that
 filtering cannot be performed server side does not meaningfully increase security, since as
 long as a field can be viewed by an end user, they can effectively search the field themselves
 even if the UI doesn't offer a means to do so. If a field should be unable to be viewed
 entirely by some users, use  viewRequiresRole and
 related settings. 
 Rather than a security setting, canFilter:false is intended
 for situations where it would be redundant or nonsensical to be able to search on a field, or
 where searching isn't implemented for that field.
 
Default value is null
public java.lang.Boolean ignoreTextMatchStyle
clientOnly DataSources and the built-in SQL,
 JPA and  Hibernate DataSources available in Pro, Power
 and  Enterprise versions of Smart GWT.  Use this flag to inhibit the normal use of TextMatchStyle for this field.  A  field with this flag set will
 always be tested for exact equality in generated queries,  even for filter-style queries where
 normal behavior would be to use a substring match or  similar. 
 Whether or not the exact
 match is case-sensitive is determined by the DataSource's  ignoreTextMatchStyleCaseSensitive setting.
 
Default value is null
public SummaryFunctionType includeSummaryFunction
field.includeFrom is
 specified and multiple records
  exist in the related DataSource per record in the including DataSource,
 includeSummaryFunction indicates which SummaryFunctionType is used to
  produce the field value.
  This feature is available with Power or better licenses only. See smartclient.com/product for details.
For example, given a DataSource "order" and related DataSource "orderItem", the "itemCount" field below will show the total number of items in each order.
   <DataSource ID="order">
      <fields>
         <field name="orderID" type="integer" primaryKey="true" foreignKey="orderItem.orderID" />
         <field name="customerName" type="text" />
         <field name="orderDate" type="date" />
         <field name="itemsCount" includeFrom="orderItem.quantity" includeSummaryFunction="sum" />
      </fields>
   </DataSource>
  
  This is analogous to the following SQL statement: 
  
  SELECT
       order.orderID,
       order.customerName,
       order.orderDate,
       (select sum(_itemsCount.quantity)
           from orderItem _itemsCount
           where _itemsCount.orderID = order.orderID) as itemsCount
  FROM
       order
  
 The includeSummaryFunction feature supports indirect inclusion as well, when the
 field using
 it is included from the other DataSource via regular includeFrom. For example,
 given the
 "order" DataSource above and related "orderItem" DataSource, the "orderItemsCount" field below
 will show the
  total number of items in the order each order item record belongs to:
  
   <DataSource ID="orderItem">
      <fields>
         <field name="id" type="integer" primaryKey="true" />
         <field name="orderID" type="integer" foreignKey="order.orderID"/>
         <field name="quantity" type="integer" />
         <field name="unitPrice" type="float" />
         <field name="orderItemsCount" includeFrom="order.itemsCount" />
      </fields>
   </DataSource>
  
  This is analogous to the following SQL statement:
  
  SELECT
       orderItem.id,
       orderItem.orderID,
       orderItem.quantity,
       orderItem.unitPrice,
       (select sum(_orderItemsCount_orderID.quantity) AS itemsCount
          from order _orderItemsCount
                   join orderItem _orderItemsCount_orderID
                       on _orderItemsCount.orderID = _orderItemsCount_orderID.orderID
          where orderItem.orderID = _orderItemsCount.orderID) as orderItemsCount
  FROM
       orderItem
  
  
 Note that tables in sub-select will always use relatedTableAlias if set
 or automatically
 generated aliases. Automatic aliases are generated according to the rule: first table in
 possible chain of
 relations being the name of the field sub-select is getting value for (with underscore "_" in
 front) and the
 rest aliases are built up using foreign key field names in the chained relations leading to the
 target table.
 This allows to avoid any conflicts with the tables/aliases from the main query. Like in the
 second example
  table "orderItem" is used in both main query without alias and sub-select under
  _orderItemsCount_orderID alias.
  
Some other common uses:
SummaryFunctionType).
  
  NOTE: includeSummaryFunction and
 Server Summaries cannot be used in the same
 DSRequest.
  If both configurations are present, Server Summaries settings always take priority.
 
Default value is null
public FieldFilterMode filterOn
client where  possible, to avoid
 server round-trips.  When this property is set to serverOnly, any change to
 criteria for this field  causes cache-invalidation and a trip to the server.
 
Default value is null
public java.lang.Integer imageHeight
ViewFileItem as
 an editor.
 Default value is null
public java.lang.String javaClass
com.isomorphic.datasource.DataSource.setProperties().  This includes 
 auto-populating POJO arguments of a DMI method, or
 populating JPA/Hibernate beans with data when using the built-in JPA and Hibernate DataSources.
  For DataSources that do not use Java Beans, javaClass can be used to force a
 particular representation for validated DSRequest data (e.g. data passed to a DMI): 
javaClass does not normally have to specified: Smart GWT will use Java reflection
 to inspect the type of argument expected by a setter method and will attempt conversion of
 inbound data to that type.  As described in the documentation for
 DataTools.setProperties(), this works for almost all typical cases.  However
 field.javaClass is useful for: javaClass should be set instead.javaClass needs to be specified.  Note that
 javaClass will take precedence over generics if both  are used. Also note that
 javaCollectionClass can be specified if a particular Collection or Map type is needed, and
 javaKeyClass can be
 specified for a field of type java.util.Map.DataSource.getPropertyJavaClass()  in the server documentation
 for details.
 Default value is null
public MultipleFieldStorage multipleStorage
multiple:true field should be stored.  On the server, field values for
 multiple:true fields are represented as Java Lists in DSRequest and DSResponse
 objects, but when multipleStorage is used, are ultimately stored as Strings.   
This storage mechanism is "denormalized" in the sense of database normalization because the field contains a compound value rather than an atomic value. Specifically, this makes the field harder to use with database features like SQL joins, since its value cannot be directly compared to other, singular fields. For this reason, there's really only a narrow set of cases where it makes sense to use this storage mechanism, consider it if:
 A
 multiple:true field can be of any SimpleType, including "date", "time", "datetime", "float",
 "int" etc.  Type will be preserved across a store and reload cycle, so for example a List of
 values for a field of type "int" will arrive at the server in a DSRequest as a List of Integer,
 be stored as a String, but appear again as a List of Integer inside a DSResponse.  When storing
 "date", "time" or "datetime" values as Strings, XML schema formats are used - the same that are
 used for transmission in XML or JSON (see Date and Time Format and Storage overview for details). 
 The multipleStorage
 feature works by transforming from List to String and back inside the server-side
 DataSource.execute() method.  Specifically, inbound DSRequests are transformed before methods
 that perform actual storage are called (executeUpdate() et al), and DSResponses received from
 these methods have multiple:true field values transformed back into Lists before
 DataSource.execute() returns the DSResponse. 
 This transformation approach means that the
 built-in SQL, JPA and Hibernate connectors all support multipleStorage, and
 multipleStorage is also automatically available for any custom DataSource that is
 capable of storing String values, and implements its storage methods via overrides of
 executeUpdate(), executeAdd() et al as described in the custom DataSource overview. 
 Note that when
 using the built-in SQL, JPA and Hibernate connectors, the underlying SQL column should be of
 'text' type.  The Database Configuration Tool
 will automatically generate columns of the correct type for a SQLDataSource.  For JPA or
 Hibernate DataSources, just ensure the type of the Java bean property on your Java object is
 String. 
 The default multipleStorage setting of null means that the
 "simpleString" MultipleFieldStorage approach will be used if:
 
SimpleType foreignKey
 MultipleFieldStorage "none" will be used.
 
 For the built-in SQL, JPA and Hibernate
 connectors, when multipleStorage:"simpleString" or "json" is used, criteria are
 transformed to replicate the client-side filtering behavior for multiple:true fields, where
 possible. The following operators are supported with the same behavior as client-side
 filtering: 
pattern operators multipleStorage: OperatorValueType of "valueRange"  multipleStorageSeparator may be used in the filter string.  If any characters from the
 multipleStorageSeparator are present in the filter value, it will always fail to
 match.  For "json" mode, the multipleStorageSeparator is effectively the String
 '","'.
 Default value is null
public java.lang.String otherFKs
foreignKey this property allows
  defining multiple foreign keys if the field is related to more than one DataSource.
  
  The format of the otherFKs is coma separated foreign key sets, for example:
  "<firstDS>.<fieldName>,<secondDS>.<fieldName>".
  Note that this property works only in addition to the regular FK, i.e. if
 foreignKey is not set,
 then foreign keys defined in otherFKs
 will be completely ignored. If otherFKs is specified, it can include the value of
 the
 foreignKey attribute or it can omit it, listing only additional foreignKeys. 
 There
  is no impact on functionality from doing it either way.
  
 For example, perhaps you have a moneyTransfer DataSource where each record
 represents
 a money transfer, which has receipt and invoice information stored in
 receiptDS and receiverDS DataSources. Each money transfer is linked
 to a
 receipt and an invoice records through the same transferDS.id field via the
 foreign keys
  defined in foreignKey and otherFKs properties:
  
  <DataSource ID="moneyTransfer" ... >
       <field name="id" primaryKey="true"
           foreignKey="receiptDS.id"
           otherFKs="invoiceDS.id"/>
       <field name="receiptInfo" includeFrom="receiptDS.info"/>
       <field name="invoiceInfo" includeFrom="invoiceDS.info"/>
  </DataSource>
  
  Here, we are including from two different related DataSources using the same
  foreignKey field.
  
 Note that otherFKs feature is meant to be used in more complex scenarios (see
 below), so if the
 example above is all that's needed, then there's no need to use otherFKs feature.
 The result
 would be the same as if foreign keys would be declared at the "other side", i.e. in
 receiptDS
 and invoiceDS DataSources via regular foreignKey property.
  
 If we extend the sample above with a parentId joining the
 moneyTransfer DataSource
 (so called "self-join" relation) and include from receiptDS and
 invoiceDS for
 the "parent" money transfer as well, then otherFKs feature must be used. The
 following
 declarations would be required to get receipt and invoice information for both the original
 money transfer
  and its "parent":
  
<field name="id" primaryKey="true" foreignKey="receiptDS.id" otherFKs="invoiceDS.id"/> <field name="receiptInfo" includeFrom="receiptDS.info"/> <field name="invoiceInfo" includeFrom="invoiceDS.info"/> <field name="parentId" foreignKey="moneyTransfer.id" relatedTableAlias="parent"/> <field name="parentReceiptInfo" includeFrom="moneyTransfer.receiptDS.info"/> <field name="parentInvoiceInfo" includeFrom="moneyTransfer.invoiceDS.info"/>
otherFKs
 Similar to the includeVia, otherFKs feature uses SQL table aliases in
 the
  generated SQL when generating multiple SQL joins to the same SQL table.  When using
 SQL Templating, it's sometimes necessary to know the names of the aliases in the
 generated
 SQL. See the "Automatically generated table aliases" section of the SQL Templating
  for the complete set of general rules how aliases are generated.
  
  The otherFKs feature uses aliases constructed from two parts:
 - the field name, which otherFKs
 property is defined on;
 - the related DataSource ID or the
 DataSource.relatedTableAlias if set.
So, in the extended sample above the aliases for the "parent" money transfer related tables would be "parent_id" (regular FK) and "parent_id_invoiceDS" (other FK).
 See below the same sample extended with the detailDS DataSource storing multiple
 records per money
 transfer, joined to moneyTransfer DataSource on a one-to-many basis, and include
 receipt and
 invoice information for money transfer and its "parent". Also, we'll add
 relatedTableAliases
  to the invoice DataSource, see all related declarations below:
  
  <DataSource ID="detailDS" ... >
       <field name="id" type="integer" primaryKey="true" >
       <field name="name"/>
       <field name="mtId" foreignKey="moneyTransfer.id" relatedTableAlias="main"/>
       <field name="mainReceipt" includeFrom="moneyTransfer.receiptInfo" includeVia="mtId"/>
       <field name="mainInvoice" includeFrom="moneyTransfer.invoiceInfo" includeVia="mtId"/>
       <field name="mainParentReceipt" includeFrom="moneyTransfer.parentReceiptInfo" includeVia="mtId"/>
       <field name="mainParentInvoice" includeFrom="moneyTransfer.parentInvoiceInfo" includeVia="mtId"/>
  </DataSource>
 
  <DataSource ID="receiptDS" ... >
       <fields>
           <field name="id" primaryKey="true"/>
           <field name="info"/>
       </fields>
  </DataSource>
 
  <DataSource ID="invoiceDS" relatedTableAlias="invoice" ... >
       <fields>
           <field name="id" primaryKey="true"/>
           <field name="info"/>
       </fields>
  </DataSource>
  
 Generated aliases for the receipt/invoice tables will be main_id,
 main_id_invoice
 for the money transfer and main_parent_id,
 main_parent_id_invoice for the "parent"
  money transfer.
  
otherFKs + includeVia
 The otherFKs and the includeVia features may be used
 together in even
 more complex scenarios. In the example below we extend detailDS DataSource with a
 link to
  the "previous" money transfer and include all of its receipt/invoice information:
  
<field name="mtPrevId" foreignKey="moneyTransfer.id" relatedTableAlias="prev"/> <field name="prevReceipt" includeFrom="moneyTransfer.receiptInfo" includeVia="mtPrevId"/> <field name="prevInvoice" includeFrom="moneyTransfer.invoiceInfo" includeVia="mtPrevId"/> <field name="prevParentReceipt" includeFrom="moneyTransfer.parentReceiptInfo" includeVia="mtPrevId"/> <field name="prevParentInvoice" includeFrom="moneyTransfer.parentInvoiceInfo" includeVia="mtPrevId"/>Additionally generated aliases will be
prev_id,
 prev_id_invoice
 for the money transfer and prev_parent_id,
 prev_parent_id_invoice
  for the "parent" money transfer.
  The inclusions may as well be indirect like shown below and they would produce same chains of relations, so the generated SQL and table aliases will be the same as above.
<field name="mtPrevId" foreignKey="moneyTransfer.id" relatedTableAlias="prev"/> <field name="prevReceipt" includeFrom="moneyTransfer.receiptDS.info" includeVia="mtPrevId"/> <field name="prevInvoice" includeFrom="moneyTransfer.invoiceDS.info" includeVia="mtPrevId"/> <field name="prevParentReceipt" includeFrom="moneyTransfer.moneyTransfer.receiptDS.info" includeVia="mtPrevId"/> <field name="prevParentInvoice" includeFrom="moneyTransfer.moneyTransfer.invoiceDS.info" includeVia="mtPrevId"/>
Default value is null
public java.lang.Boolean implicitSequence
type "sequence" on a DataSource with
 serverType:"sql", this flag
 indicates that the field is  implicitly bound to a sequence.  This setting means that Smart GWT
 does not expect to  find a value for the field in "add" operations, even if it is marked as a 
 primaryKey, as such fields
 usually are.  It also means that Smart GWT does not attempt to retrieve the field value from an
 actual database sequence, instead relying on the JDBC driver to return the generated value (see
 the note on sequenceMode below). Implicitly bound columns are a syntactic convenience provided by some databases to simulate the "auto-increment" or "identity" columns available natively in other products, without the underlying sequence having to be explicitly referenced in SQL queries. Currently, these database products support this idea:
implicitSequence flag.  NOTE: If you use this property, you
 should also set the  DataSource sequenceMode to "jdbcDriver".  This is necessary because Smart GWT cannot directly
 query the implicit sequence that is being used behind the  scenes, so we must rely on the JDBC
 driver to do that. 
 If you use autoDeriveSchema to
 automatically derive a  dataSource from table metadata, Smart GWT attempts to identify these
 special Oracle and Postgres columns by heuristic examination of the metadata.  When it
 identifies such a  column, it marks the corresponding dataSourceField implicitSequence:
 true,  and changes the sequenceMode on the DataSource to "jdbcDriver".  If your table
 contains one of these columns and Smart GWT does not automatically identify it, bear in mind
 that you can always set this flag manually, even if you are using
 autoDeriveSchema. 
This setting has no effect for non-SQL dataSources, or for databases other than those mentioned above.
Default value is null
public java.lang.Integer decimalPad
For example, a field value of 343.1, 343.104 and 343.09872677 would all be shown as 343.10 if decimalPad is 2.
The original unpadded value is always shown when the value is edited.
Default value is null
Appearance overview and related methodspublic java.lang.String multipleValueSeparator
multiple:true, the separator used  between values when they are displayed.
 Default value is ", "
public java.lang.String updateRequiresRole
 NOTE: This property only prevents a field from being updated; initialization will  still
 be allowed.  You should only use this property if you have a special requirement;  ordinarily,
 use editRequiresRole, which applies security for both  types of write.
 
Default value is null
public VelocityExpression editRequires
VelocityExpression must evaluate
 to true if writes to this field are to be allowed.  If the specified expression does not
 evaluate to true, the field will be removed from the request as described for  editRequiresAuthentication.  In addition to the normal context variables available to
 Velocity expressions in Smart GWT, expressions you write for field-level requires
 clauses - editRequires,  viewRequires, initRequires and  updateRequires - can
 reference two additional variables:  $fieldName and $dsName.  These
 are the names of the dataSource and  field currently undergoing requires checks. 
 They are helpful because they allow you to write a generic checker function that can be used to
 handle requires checks for multiple fields and dataSources. 
 NOTE: This
 property prevents both initialization and updates for a field.  If you  have a need to prevent
 just initialization or just updates, you can use initRequires or updateRequires.
 
Default value is null
public java.lang.String foreignDisplayField
foreignKey relationship
  exists.  Derived automatically when using the displayField / includeFrom pattern as
  illustrated in the following example.
  
  For a general overview on picking up display values from a separate field,
 see displayField
 property.
  
  The foreignDisplayField property is useful for editable fields, where the 
  name of the display field within the record being edited differs from the display field 
  for related records in the option dataSource.
  For example consider a "countryDS" dataSource with the following fields:
  
<field name="id" type="sequence" hidden="true" primaryKey="true" /> <field name="name" type="text" title="Country" required="true" />...and a "city" dataSource which uses a foreignKey relationship identify associated country records:
   <field name="id"        type="sequence" hidden="true"   primaryKey="true" />
   <field name="name"      type="text"     title="City"    required="true" />
   <field name="countryId" type="integer"  editorType="SelectItem" 
              foreignKey="countryDS.id" 
              displayField="countryName" foreignDisplayField="name" title="Country" />
   <field name="countryName" includeFrom="countryDS.name"  hidden="true"   />
  
  A DynamicForm bound to this "city" dataSource would display a SelectItem editor by
  default for the country field. The initial display value would be the local value from
  the "countryName" field, populated from the related countryDS automatically via the
  includeFrom feature.
  Note that when specified, foreignDisplayField is always expected to be set to 
  the related dataSource field containing equivalent values to the displayField
 in the local dataSource. This is important as, when editing the field, foreignDisplayField
 values from 
  the related dataSource will be displayed to the user, and when a value is selected
  the local record's displayField value will be updated to match the selected
  foreignDisplayField value from the related dataSource's record. This behavior
 is documented under FormItem.displayField.
 
Default value is null
public java.lang.String batchUploadOperationId
importStrategy.display while
 importing data using BatchUploader or
 DataImport server-side API.  Normally key values are looked up performing
 "fetch" operation on related data source, but setting batchUploadOperationId
 allows to control which operation will be performed. This can be useful to avoid unnecessary
 load when importing big data sets, if default "fetch" operation is too heavy. 
 By default
 the look up is not case sensitive but this can be controlled through the batchUploadCaseSensitive attribute.
 
Default value is null
public java.lang.String exportTitle
Default value is null
public java.lang.String displayField
ListGrid, the displayField attribute may be used
 to cause some  field to display a value from another field in the record.  This is typically
 used for editable foreignKey fields.  In this scenario, a dataSource field has a foreignKey field which stores
 an ID value used to identify records in another, related dataSource. Rather than display this
 ID to users, developers may wish to display another, user-friendly field from the related
 record. This is easy to achieve by  having a second field on the dataSource which will be
 populated with the "display value" from this related dataSource, and using
 dataSourceField.displayField  to show this value.  The includeFrom feature handles
 populating this field automatically for dataSources backed by the Smart GWT Server. See the "Editing included
 fields" section of the includeFrom documentation for more on editing included foreignKey fields. 
 Editable
 dataSourceFields with a specified displayField and  foreignKey will
 typically be edited using a SelectItem  or
 ComboBoxItem. In this case, in addition to
 identifying the field to use as a static display value within the record being edited,
 displayField will also identify which field on the related dataSource to use as a
 display field when showing a set of options to the user. This behavior may be modified in a
 couple of ways: 
foreignDisplayField
 attribute may be used to handle the      case where the name of the field used as a
 displayField within the dataSource is      different from the name of the included/equivalent
 field in the related dataSource.useLocalDisplayFieldValue attribute may be explicitly      set to false to avoid picking up a
 display value from the local record altogether.      Instead the displayField will be used only
 to derive the display value from      a related record from the optionDataSourceFormItem.displayField.
 Default value is null
public java.lang.Boolean nillable
xsi:nil being used to transmit the value when serializing
  to XML, like so:
  
  <book>
      <title>Beowulf</title>
      <author xsi:nil="true"/>
  </book>
  
  If nillable is not set, no XML element will be generated for
  the explicit null value.
  
  A DataSourceField that specifies a foreignKey is automatically nillable
  unless this property is explicitly set to false.
 
Default value is null
public java.lang.String uploadFieldName
BatchUploader to map a field in an upload file
 to this  dataSourceField.  This is only necessary if the dataSourceField's name and title
 differ  from the name of the field in the upload file (Smart GWT will automatically map upload 
 fields using the dataSourceField's title, if possible, if it does not get a direct match  on
 field name).
 Default value is null
public java.lang.Boolean encodeInResponse
 When encodeInResponse is not set normal responses will not contain
 values for binary fields at all.  Instead, UI components, such as TileGrid issue a second binary fetch for binary data when
 appropriate, and APIs such as downloadFile() and viewFile() can be used
 to programmatically trigger downloads. 
 Only applicable to fields of a type that are
 represented by binary data (currently "binary" and "imageFile", see FieldType).
 
Default value is null
public java.lang.Integer imageSize
ViewFileItem as an editor.
 Default value is null
public OperatorId defaultOperator
 If not specified, falls back to the default
 specified for the field's data-type.
 
Default value is null
public java.lang.Integer precision
For example, a field value of 343.1, 343.104 and 343.09872677 would all be shown as 343.10 if precision is 5.
The original value is always shown when the value is edited.
Default value is null
Appearance overview and related methodspublic FieldImportStrategy importStrategy
FieldImportStrategy for this field.  The default setting of null  has
 the same meaning as "auto".  Note, this attribute only has an effect if all of the  following
 are true:foreignKeydisplayFieldincluded from the  same
 DataSource that the foreignKey declaration refers to importStrategy is applied by the
 server-side  DataImport.importToRows() method, which is in turn used by BatchUploader and several other DataImport APIs such as 
 importToDataSource(), importDataSourceRecords() and 
 importAndValidateDSRows().  See the server-side documentation for details of these
 APIs.  The actual data transformation is carried out by the  server-side API
 DataSource.transformImportValue(); this method can  be overridden to carry out any
 other transformation you may require.
 
Default value is null
batchUploadOperationIdpublic java.lang.Boolean childrenProperty
DataSource.childrenField to this
 field's  name.
 Default value is false
public java.lang.Boolean multiple
XML or JSON data is singular,
 it will be wrapped in an Array.
  
  JPA and Hibernate DataSources use multiple:true as part of the declaration of
 One-To-Many and Many-to-Many relations - see JpaHibernateRelations for details.
  
  For simple Criteria, the criteria value is compared to each field value in the
  multiple:true field, according to the
 textMatchStyle.  If any
 field value matches the
 j filter value, the field is considered to match the criteria.
  
 For AdvancedCriteria, for normal search operators the field
  value is considered as matching the Criterion if any of the field values
  match the Criterion.  Specifically, this is true of all operators that have an 
 operatorValueType of "fieldType" or
 "valueRange".
  
  For operators that compare against other fields in same record, such as "equalsField", 
  if the other field is not multiple:true, matching works the same as for
  normal operators, that is, as if criterion.value directly contained the value
  rather than the name of another field.
  
  If the other field is also multiple:true, only "equalsField", "notEqualsField",
  "iEqualsField" and "iNotEqualsField" are allowed (any other operator will
  cause a warning and be ignored) and the set of values in the field must be identical (aside
  from case, for operators prefixed with "i") and in identical order to match.
  
  For the inSet operator, the field matches if there is any intersection between
  the field values and the array of values provided in criterion.value.
  notInSet is the reverse.
  
"Finally, for "isNull" and "notNull", an empty Array is considered non-null, however, for "isBlank" and "notBlank", an empty Array is considered blank, since a control such as a multiple:true SelectItem or MultiComboBoxItem would appear blank to the end user if it had an empty Array as its value.
  Values for multiple:true fields appear as Java Lists when received in server code such as a
 DMI.  The Smart GWT Server supports simple storage of values that are multiple:true, controlled
 via the multipleStorage setting.
  
  For server-side behavior of JPA and Hibernate relation fields that are multiple:true, see
  JpaHibernateRelations.
  
  For non-relation fields, the Smart GWT Server supports simple storage of values that are
 multiple:true, controlled via the multipleStorage setting,
 with some limited support
 for server-side filtering, as described in the multipleStorage docs.
  
  For the built-in SQL, Hibernate and JPA connectors, if criteria are specified for a
  multiple:true field where multipleStorage is null or "none", the Smart GWT
  server knows nothing about how the multiple values are stored, so as a fallback the criteria
  will operate as though the field were a normal, non-multiple "text" field.  This will
  generally not match the client-side filtering behavior described above, so filtering
  should either be performed entirely on the client (for example, via
 dataFetchMode:"local" or
 entirely on the server (via
 ResultSet.useClientFiltering:"false")
  
  The server-side filtering is done through a criteria transform which happens with
 transformMultipleFields.
  
  Specifically for XML serialization and deserialization, multiple:true behaves
  similarly to the 
 SOAP array idiom,
 that is,
  there will be a "wrapper element" named after the field name, whose contents will be several
 elements of the specified field.type.  
  
 For example, Layout.members is
 declared with type:"Canvas",
  multiple:true.  The correct XML format is thus:
  
  <VLayout>
      <members>
          <Canvas ID="myCanvas" ... />
          <ListGrid ID="myGrid" .../>
          <Toolstrip ID="myToolStrip" ... />
      </members>
  </VLayout>
  
  
 See childTagName for
 customizing the tagName used for subelements.
 
Default value is false
public java.lang.Boolean lenientXPath
valueXPath for this field should not perform any validation at all and will return null for
 non existing XPaths. Otherwise warning message will be logged for non-existing XPath or with
 null objects in the middle of XPath. NOTE: this applies to server-side processing of valueXPath only.
Default value is null
public FieldType type
Field type may imply automatic validators (for example, an integer field cannot accept the value "foo"). Field type also affects the default behaviors of DataBound components, for example, if a field is declared as type "date", components that edit that field will automatically choose a date-editing interface with pop-up date picker.
Default value is null
Basics overview and related methodspublic VelocityExpression viewRequires
VelocityExpression must evaluate
 to true if values for the field are to be fetched.  If the specified expression does not
 evaluate to true, the field will be dropped as described for  viewRequiresAuthentication.  In addition to the normal context variables available to
 Velocity expressions in Smart GWT, expressions you write for field-level requires
 clauses - viewRequires,  editRequires, initRequires and  updateRequires - can
 reference two additional variables:  $fieldName and $dsName.  These
 are the names of the dataSource and  field currently undergoing requires checks. 
 They are helpful because they allow you to write a generic checker function that can be used to
 handle requires checks for multiple fields and dataSources.
 
Default value is null
public boolean detail
DataBoundComponent.  Detail fields won't be shown by default in
 a DataBoundComponent where  DataBoundComponent.showDetailFields is false.  This allows for some DataBound components, like
 a ListGrid, to show a summary view of records which
 displays only  the most commonly viewed fields by default, while other DataBoundComponents,
 like a DetailViewer, show all fields by default. 
 In addition, the formItem.showIf property is supported in multiple components for conditional visibility - see
 for example ListGridField.showIf() and FormItem.showIf()).
 
Default value is false
public java.lang.String fkTableCode
DataSource.tableCode.
 Default value is null
public java.lang.Boolean propertiesOnly
ComponentSchema for fields that contain other
 components, this flag
  suppresses auto-construction for subcomponents that appear under this field.
  
 For example, the VLayout schema sets this for its
 members
  property, so that when a VLayout is constructed via XML as follows:
  
  <VLayout>
      <members>
          <ListGrid ID="myGrid" .../>
          <Toolstrip ID="myToolStrip" ... />
      </members>
  </VLayout>
  
  The ListGrid and ToolStrip do not construct themselves automatically.  Instead, the VLayout
  receives the properties of the ListGrid and ToolStrip as ordinary JavaScript Objects, with
  the special property _constructor set to the name of the class that should be
  constructed.
 Default value is null
public FormatString format
DataBoundComponent or when exporting via DataSource.exportData() or ListGrid.exportData() or  ListGrid.exportClientData(). 
 Supported for fields of type "date", "time", "datetime", "int", "float" or any derived SimpleType.  
 To configure a different format for export,
 use exportFormat. 
 This is a per-field setting; you can alternatively set a default format for all "date", "time"
 or "datetime" fields via    DateUtil.setNormalDatetimeDisplayFormat() and related methods on com.smartgwt.client.util.Date.  See also LocalizedNumberFormatting for built-in FieldTypes that handle localized currency formatting. 
 Also note, this property takes precedence over any specified  dateFormatter, but can be overridden
 on a per-component basis by providing a formatter directly on the component, for example, via
 ListGrid.setCellFormatter()
 or FormItem.formatValue().
 
Default value is null
exportFormat