Constructor Detail

• DSRequest

  public DSRequest()

• DSRequest

  public DSRequest(com.google.gwt.core.client.JavaScriptObject jsObj)

• DSRequest

  public DSRequest(DSOperationType operationType)

• DSRequest

  public DSRequest(DSOperationType operationType,
                   java.lang.String operationId)

• DSRequest

  public DSRequest(DSOperationType operationType,
                   Record data)

• DSRequest

  public DSRequest(DSOperationType operationType,
                   java.lang.String operationId,
                   Record data)

• DSRequest

  public DSRequest(DSOperationType operationType,
                   com.google.gwt.core.client.JavaScriptObject data)

• DSRequest

  public DSRequest(DSOperationType operationType,
                   java.lang.String operationId,
                   com.google.gwt.core.client.JavaScriptObject data)

• DSRequest

  public DSRequest(DSOperationType operationType,
                   Criteria criteria)

• DSRequest

  public DSRequest(DSOperationType operationType,
                   java.lang.String operationId,
                   Criteria criteria)

Method Detail

• getOrCreateRef

  public static DSRequest getOrCreateRef(com.google.gwt.core.client.JavaScriptObject jsObj)

• setAdditionalOutputs

  public DSRequest setAdditionalOutputs(java.lang.String additionalOutputs)

  For fetch, add or update operation, an optional comma separated list of fields to fetch from another, related DataSource.

  Fields should be specified in the format "localFieldName!relatedDataSourceID.relatedDataSourceFieldName". where relatedDataSourceID is the ID of the related dataSource, and relatedDataSourceFieldName is the field for which you want to fetch related values. The returned field values will be stored on the data returned to the client under the specified localFieldName. Note that this will be applied in addition to any specified outputs.

  Note that as with DataSourceField.includeFrom, the related dataSource must be linked to the primary datasource via a foreignKey relationship.

  Note additionalOutputs sent in request from the browser can be completely disabled in server.properties by setting datasource.allowClientAdditionalOutputs:

        datasource.allowClientAdditionalOutputs: false
    

  In this case additionalOutputs sent from the browser will be cleared before executing request. Note that programatically configured additionalOutputs are always allowed, but you can't modify them from within a DMI method, so the only way to execute a request with additionalOutputs that differ from what was sent by the client is to create a new DSRequest

  Note : This is an advanced setting

  Parameters:

  additionalOutputs - New additionalOutputs value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getAdditionalOutputs

  public java.lang.String getAdditionalOutputs()

  For fetch, add or update operation, an optional comma separated list of fields to fetch from another, related DataSource.

  Fields should be specified in the format "localFieldName!relatedDataSourceID.relatedDataSourceFieldName". where relatedDataSourceID is the ID of the related dataSource, and relatedDataSourceFieldName is the field for which you want to fetch related values. The returned field values will be stored on the data returned to the client under the specified localFieldName. Note that this will be applied in addition to any specified outputs.

  Note that as with DataSourceField.includeFrom, the related dataSource must be linked to the primary datasource via a foreignKey relationship.

  Note additionalOutputs sent in request from the browser can be completely disabled in server.properties by setting datasource.allowClientAdditionalOutputs:

        datasource.allowClientAdditionalOutputs: false
    

  In this case additionalOutputs sent from the browser will be cleared before executing request. Note that programatically configured additionalOutputs are always allowed, but you can't modify them from within a DMI method, so the only way to execute a request with additionalOutputs that differ from what was sent by the client is to create a new DSRequest

  Returns:

  Current additionalOutputs value. Default value is null

• setArrayCriteriaForceExact

  public DSRequest setArrayCriteriaForceExact(java.lang.Boolean arrayCriteriaForceExact)

  DSRequest-level override for the DataSource-level arrayCriteriaForceExact flag. See the documentation for that flag for details.

  Parameters:

  arrayCriteriaForceExact - New arrayCriteriaForceExact value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  Server DataSource Integration

• getArrayCriteriaForceExact

  public java.lang.Boolean getArrayCriteriaForceExact()

  DSRequest-level override for the DataSource-level arrayCriteriaForceExact flag. See the documentation for that flag for details.

  Returns:

  Current arrayCriteriaForceExact value. Default value is null

  See Also:

  Server DataSource Integration

• setComponentId

  public DSRequest setComponentId(java.lang.String componentId)

  For requests submitted by a DataBoundComponent, the Canvas.ID of the submitting component.

  This ID will be present for operations including automatic saves by a ListGrid during editing, or calls to form.saveData(). It will not be present for a direct call to a DataSource method such as DataSource.fetchData().

  Note this is the component's String ID - you can retrieve the component itself via Canvas.getById().

  This property should be used for debugging purposes only - do not use it to trigger differences in server-side behavior, instead, use operationId because only operationId is considered when assessing request equivalence.

  Parameters:

  componentId - New componentId value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getComponentId

  public java.lang.String getComponentId()

  For requests submitted by a DataBoundComponent, the Canvas.ID of the submitting component.

  This ID will be present for operations including automatic saves by a ListGrid during editing, or calls to form.saveData(). It will not be present for a direct call to a DataSource method such as DataSource.fetchData().

  Note this is the component's String ID - you can retrieve the component itself via Canvas.getById().

  This property should be used for debugging purposes only - do not use it to trigger differences in server-side behavior, instead, use operationId because only operationId is considered when assessing request equivalence.

  Returns:

  Current componentId value. Default value is null

• setDataProtocol

  public DSRequest setDataProtocol(DSProtocol dataProtocol)

  DataProtocol for this particular request.

  Note: Typically developers should use operation bindings to specify an explicit data protocol for a request.

  One exception: advanced developers may wish to have a custom request transformer with entirely client-side handling for some requests. This may be achieved by setting the request's dataProtocol to "clientCustom" within transformRequest, and also triggering application code which will fire DataSource.processResponse() when complete.

  The DataSource.getDataProtocol() method may be used to determine what data protocol will be used to handle a specific request based on this property (if set), otherwise the settings at the operationBinding or dataSource levels.

  Parameters:

  dataProtocol - New dataProtocol value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getDataProtocol

  public DSProtocol getDataProtocol()

  DataProtocol for this particular request.

  Note: Typically developers should use operation bindings to specify an explicit data protocol for a request.

  One exception: advanced developers may wish to have a custom request transformer with entirely client-side handling for some requests. This may be achieved by setting the request's dataProtocol to "clientCustom" within transformRequest, and also triggering application code which will fire DataSource.processResponse() when complete.

  The DataSource.getDataProtocol() method may be used to determine what data protocol will be used to handle a specific request based on this property (if set), otherwise the settings at the operationBinding or dataSource levels.

  Returns:

  Current dataProtocol value. Default value is null

• setDataSource

  public DSRequest setDataSource(java.lang.String dataSource)

  DataSource this DSRequest will act on.

  This property is generally automatically populated, for example when calling DataSource.fetchData() the dataSource property is set to the target DataSource.

  Parameters:

  dataSource - New dataSource value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getDataSource

  public java.lang.String getDataSource()

  DataSource this DSRequest will act on.

  This property is generally automatically populated, for example when calling DataSource.fetchData() the dataSource property is set to the target DataSource.

  Returns:

  Current dataSource value. Default value is null

• setEndRow

  public DSRequest setEndRow(java.lang.Integer endRow)

  End row of requested results, used only with fetch operations.

  Note that startRow and endRow are zero-based, inclusive at the beginning and exclusive at the end (like substring), so startRow: 0, endRow: 1 is a request for the first record.

  Parameters:

  endRow - New endRow value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getEndRow

  public java.lang.Integer getEndRow()

  End row of requested results, used only with fetch operations.

  Note that startRow and endRow are zero-based, inclusive at the beginning and exclusive at the end (like substring), so startRow: 0, endRow: 1 is a request for the first record.

  Returns:

  Current endRow value. Default value is null

• setExportAs

  public DSRequest setExportAs(ExportFormat exportAs)

  The format in which the data should be exported. Note that 'JSON' is not allowed as a client-side option. See ExportFormat for more information.

  Parameters:

  exportAs - New exportAs value. Default value is "csv"

  Returns:

  DSRequest instance, for chaining setter calls

• getExportAs

  public ExportFormat getExportAs()

  The format in which the data should be exported. Note that 'JSON' is not allowed as a client-side option. See ExportFormat for more information.

  Returns:

  Current exportAs value. Default value is "csv"

• setExportCSS

  public DSRequest setExportCSS(java.lang.String exportCSS)

  When using RPCManager.exportContent() to produce a .pdf from a Smart GWT UI, this property allows dynamic CSS to be passed to the server. Since the exportContent() system already provides a way to specify a custom skin or additional stylesheet for export, exportCSS should only be used for small bits of CSS that are necessarily dynamic.

  For example, when printing a very wide page, such as a grid with many columns or a very wide chart, you could send the string "@page {size: A4 landscape; }" as exportCSS to cause the generated PDF to use landscape mode, so that all content fits without clipping.

  Parameters:

  exportCSS - New exportCSS value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getExportCSS

  public java.lang.String getExportCSS()

  When using RPCManager.exportContent() to produce a .pdf from a Smart GWT UI, this property allows dynamic CSS to be passed to the server. Since the exportContent() system already provides a way to specify a custom skin or additional stylesheet for export, exportCSS should only be used for small bits of CSS that are necessarily dynamic.

  For example, when printing a very wide page, such as a grid with many columns or a very wide chart, you could send the string "@page {size: A4 landscape; }" as exportCSS to cause the generated PDF to use landscape mode, so that all content fits without clipping.

  Returns:

  Current exportCSS value. Default value is null

• setExportData

  public DSRequest setExportData(Record... exportData)

  Only applies to request properties passed to ListGrid.exportClientData(). If specified this property contains an arbitrary set of data to be exported.

  Parameters:

  exportData - New exportData value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getExportData

  public Record[] getExportData()

  Only applies to request properties passed to ListGrid.exportClientData(). If specified this property contains an arbitrary set of data to be exported.

  Returns:

  Current exportData value. Default value is null

• setExportDatesAsFormattedString

  public DSRequest setExportDatesAsFormattedString(java.lang.Boolean exportDatesAsFormattedString)

  When exporting via ListGrid.exportClientData() to an XLS or OOXML spreadsheet, forces dates to export as a string rather than a true date value.

  If a date value is provided to a spreadsheet as a string, Excel or other spreadsheet applications may not recognize them as being date values that are valid for use in date-specific functions in formulas, filters, etc.

  For this reason, the default behavior of exportClientData is to provide date values to the spreadsheet as true date values. If Format Strings are provided via properties like dataSourceField.format these will be translated to Excel / OpenOffice format strings and used when generating spreadsheets. Other formatting logic, such as cell formatters, will not be used since they cannot be automatically translated to an Excel format string. If no translatable format string is available, date values will be provided to the spreadsheet with no formatter and the spreadsheet program's default formatting for date values will be used.

  If exportDatesAsFormattedString is set to true, date fields will appear as strings that exactly match the formatting shown in the DataBoundComponent. As noted above, this means the spreadsheet program will not recognize the value as a date.

  Parameters:

  exportDatesAsFormattedString - New exportDatesAsFormattedString value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  DataSourceField.setExportFormat(java.lang.String), Exports & Formatting

• getExportDatesAsFormattedString

  public java.lang.Boolean getExportDatesAsFormattedString()

  When exporting via ListGrid.exportClientData() to an XLS or OOXML spreadsheet, forces dates to export as a string rather than a true date value.

  If a date value is provided to a spreadsheet as a string, Excel or other spreadsheet applications may not recognize them as being date values that are valid for use in date-specific functions in formulas, filters, etc.

  For this reason, the default behavior of exportClientData is to provide date values to the spreadsheet as true date values. If Format Strings are provided via properties like dataSourceField.format these will be translated to Excel / OpenOffice format strings and used when generating spreadsheets. Other formatting logic, such as cell formatters, will not be used since they cannot be automatically translated to an Excel format string. If no translatable format string is available, date values will be provided to the spreadsheet with no formatter and the spreadsheet program's default formatting for date values will be used.

  If exportDatesAsFormattedString is set to true, date fields will appear as strings that exactly match the formatting shown in the DataBoundComponent. As noted above, this means the spreadsheet program will not recognize the value as a date.

  Returns:

  Current exportDatesAsFormattedString value. Default value is null

  See Also:

  DataSourceField.getExportFormat(), Exports & Formatting

• setExportDelimiter

  public DSRequest setExportDelimiter(java.lang.String exportDelimiter)

  The character to use as a field-separator in CSV exports. The default delimiter is comma.

  Parameters:

  exportDelimiter - New exportDelimiter value. Default value is ","

  Returns:

  DSRequest instance, for chaining setter calls

• getExportDelimiter

  public java.lang.String getExportDelimiter()

  The character to use as a field-separator in CSV exports. The default delimiter is comma.

  Returns:

  Current exportDelimiter value. Default value is ","

• setExportDisplay

  public DSRequest setExportDisplay(ExportDisplay exportDisplay)

  Specifies whether the exported data will be downloaded as an attachment or displayed in a new browser window. See ExportDisplay for more information.

  Parameters:

  exportDisplay - New exportDisplay value. Default value is "download"

  Returns:

  DSRequest instance, for chaining setter calls

• getExportDisplay

  public ExportDisplay getExportDisplay()

  Specifies whether the exported data will be downloaded as an attachment or displayed in a new browser window. See ExportDisplay for more information.

  Returns:

  Current exportDisplay value. Default value is "download"

• setExportFields

  public DSRequest setExportFields(java.lang.String... exportFields)

  The list of field names to export. If provided, the field list in the exported output is limited and sorted as per the list.

  If exportFields is not provided:

  • If we are exporting via exportData(), the field list in the exported output is every non-hidden field defined in the DataSource, in DataSource definition order
  • If we are exporting via exportClientData() and we are not exporting to OOXML, or we are exporting to OOXML but we are not streaming, the field list in the exported output is based on the client data sent up, taking every row into account (so if there is a value for field "foo" only in row 57, we will output a column "foo", the cells of which are empty except for row 57)
  • If we are exporting via exportClientData() and we are exporting to OOXML and streaming is in force (the default for OOXML), the field list in the exported output is based on the client data sent up, taking just the first row into account (so if there is a value for field "foo" only in row 57, we will not output a column "foo" at all)

  Parameters:

  exportFields - New exportFields value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getExportFields

  public java.lang.String[] getExportFields()

  The list of field names to export. If provided, the field list in the exported output is limited and sorted as per the list.

  If exportFields is not provided:

  • If we are exporting via exportData(), the field list in the exported output is every non-hidden field defined in the DataSource, in DataSource definition order
  • If we are exporting via exportClientData() and we are not exporting to OOXML, or we are exporting to OOXML but we are not streaming, the field list in the exported output is based on the client data sent up, taking every row into account (so if there is a value for field "foo" only in row 57, we will output a column "foo", the cells of which are empty except for row 57)
  • If we are exporting via exportClientData() and we are exporting to OOXML and streaming is in force (the default for OOXML), the field list in the exported output is based on the client data sent up, taking just the first row into account (so if there is a value for field "foo" only in row 57, we will not output a column "foo" at all)

  Returns:

  Current exportFields value. Default value is null

• setExportFilename

  public DSRequest setExportFilename(java.lang.String exportFilename)

  The name of the file to save the exported data into. If exportToFilesystem is set, this is the name of the file the server creates on its filesystem. If exportToClient is set, this is the filename that will appear to the browser.

  If the exportFilename that you specify does not include an extension, one will be added to it based on the ExportFormat specified by exportAs. Filename is forced to have the correct extension to work around bugs in IE, but if you don't want the filename to be manipulated, use "custom" exportFormat, see example.

  Parameters:

  exportFilename - New exportFilename value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  setExportPath(java.lang.String), Custom Export (Custom Response) Example

• getExportFilename

  public java.lang.String getExportFilename()

  The name of the file to save the exported data into. If exportToFilesystem is set, this is the name of the file the server creates on its filesystem. If exportToClient is set, this is the filename that will appear to the browser.

  If the exportFilename that you specify does not include an extension, one will be added to it based on the ExportFormat specified by exportAs. Filename is forced to have the correct extension to work around bugs in IE, but if you don't want the filename to be manipulated, use "custom" exportFormat, see example.

  Returns:

  Current exportFilename value. Default value is null

  See Also:

  getExportPath(), Custom Export (Custom Response) Example

• setExportFooter

  public DSRequest setExportFooter(java.lang.String exportFooter)

  Optional text to appear at the end of the file.

  Parameters:

  exportFooter - New exportFooter value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getExportFooter

  public java.lang.String getExportFooter()

  Optional text to appear at the end of the file.

  Returns:

  Current exportFooter value. Default value is null

• setExportHeader

  public DSRequest setExportHeader(java.lang.String exportHeader)

  Optional text to appear at the beginning of the file.

  Parameters:

  exportHeader - New exportHeader value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getExportHeader

  public java.lang.String getExportHeader()

  Optional text to appear at the beginning of the file.

  Returns:

  Current exportHeader value. Default value is null

• setExportHeaderless

  public DSRequest setExportHeaderless(java.lang.Boolean exportHeaderless)

  This property allows omitting column names from CSV and Excel exports (no effect on JSON or XML exports).

  Parameters:

  exportHeaderless - New exportHeaderless value. Default value is false

  Returns:

  DSRequest instance, for chaining setter calls

• getExportHeaderless

  public java.lang.Boolean getExportHeaderless()

  This property allows omitting column names from CSV and Excel exports (no effect on JSON or XML exports).

  Returns:

  Current exportHeaderless value. Default value is false

• setExportImageFormat

  public DSRequest setExportImageFormat(ExportImageFormat exportImageFormat)

  The image format in which the SVG graphic should be exported.

  Parameters:

  exportImageFormat - New exportImageFormat value. Default value is "png"

  Returns:

  DSRequest instance, for chaining setter calls

• getExportImageFormat

  public ExportImageFormat getExportImageFormat()

  The image format in which the SVG graphic should be exported.

  Returns:

  Current exportImageFormat value. Default value is "png"

• setExportImageQuality

  public DSRequest setExportImageQuality(java.lang.Float exportImageQuality)

  Deprecated. GwtFloatVsDouble
  If exporting in JPEG format, the output JPEG quality level. This is a number from 0 to 1, with 1 representing the best quality and 0 representing the least quality but smallest file size.

  Parameters:

  exportImageQuality - New exportImageQuality value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getExportImageQuality

  public java.lang.Float getExportImageQuality()

  Deprecated. GwtFloatVsDouble
  If exporting in JPEG format, the output JPEG quality level. This is a number from 0 to 1, with 1 representing the best quality and 0 representing the least quality but smallest file size.

  Returns:

  Current exportImageQuality value. Default value is null

• setExportImageQuality

  public DSRequest setExportImageQuality(java.lang.Double exportImageQuality)

  If exporting in JPEG format, the output JPEG quality level. This is a number from 0 to 1, with 1 representing the best quality and 0 representing the least quality but smallest file size.

  Parameters:

  exportImageQuality - New exportImageQuality value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getExportImageQualityAsDouble

  public java.lang.Double getExportImageQualityAsDouble()

  If exporting in JPEG format, the output JPEG quality level. This is a number from 0 to 1, with 1 representing the best quality and 0 representing the least quality but smallest file size.

  Returns:

  Current exportImageQuality value. Default value is null

• setExportNumbersAsFormattedString

  public DSRequest setExportNumbersAsFormattedString(java.lang.Boolean exportNumbersAsFormattedString)

  When exporting via ListGrid.exportClientData() to an XLS or OOXML spreadsheet, forces numbers to export as a string rather than a true numerical value.

  If a number is provided to a spreadsheet as a string, Excel or other spreadsheet applications may not recognize them as being numbers that are valid for use in numerical formulas, filters, etc.

  For this reason, the default behavior of exportClientData is to provide numerical values to the spreadsheet as true numbers. If Format Strings are provided via properties like dataSourceField.format these will be translated to Excel / OpenOffice format strings and used when generating spreadsheets. Other formatting logic, such as cell formatters, will not be used since they cannot be automatically translated to an Excel format string. If no translatable format string is available, numbers will be provided to the spreadsheet with no formatter and the spreadsheet program's default formatting for numerical values will be used.

  If exportNumbersAsFormattedString is set to true, numbers will appear as strings that exactly match the formatting shown in the DataBoundComponent. As noted above, this means the spreadsheet program will not recognize the value as a number.

  Parameters:

  exportNumbersAsFormattedString - New exportNumbersAsFormattedString value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  DataSourceField.setExportFormat(java.lang.String), Exports & Formatting

• getExportNumbersAsFormattedString

  public java.lang.Boolean getExportNumbersAsFormattedString()

  When exporting via ListGrid.exportClientData() to an XLS or OOXML spreadsheet, forces numbers to export as a string rather than a true numerical value.

  If a number is provided to a spreadsheet as a string, Excel or other spreadsheet applications may not recognize them as being numbers that are valid for use in numerical formulas, filters, etc.

  For this reason, the default behavior of exportClientData is to provide numerical values to the spreadsheet as true numbers. If Format Strings are provided via properties like dataSourceField.format these will be translated to Excel / OpenOffice format strings and used when generating spreadsheets. Other formatting logic, such as cell formatters, will not be used since they cannot be automatically translated to an Excel format string. If no translatable format string is available, numbers will be provided to the spreadsheet with no formatter and the spreadsheet program's default formatting for numerical values will be used.

  If exportNumbersAsFormattedString is set to true, numbers will appear as strings that exactly match the formatting shown in the DataBoundComponent. As noted above, this means the spreadsheet program will not recognize the value as a number.

  Returns:

  Current exportNumbersAsFormattedString value. Default value is null

  See Also:

  DataSourceField.getExportFormat(), Exports & Formatting

• setExportPath

  public DSRequest setExportPath(java.lang.String exportPath)

  If exportToFilesystem is set, optionally specifies a path to use when saving the file. This path is relative to the default export path, which is set using the server.properties setting export.location; this is the project webRoot by default. For example, with the default setting of export.location, an exportPath of "shared/ds" and an exportFilename of "exportedData.csv", Smart GWT Server would export to file $webRoot/shared/ds/exportedData.csv.

  If you do not specify this property, Smart GWT Server will export to the file indicated by exportFilename directly in the default export location.

  This property is only applicable when exportToFilesystem is set.

  Parameters:

  exportPath - New exportPath value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  setExportFilename(java.lang.String)

• getExportPath

  public java.lang.String getExportPath()

  If exportToFilesystem is set, optionally specifies a path to use when saving the file. This path is relative to the default export path, which is set using the server.properties setting export.location; this is the project webRoot by default. For example, with the default setting of export.location, an exportPath of "shared/ds" and an exportFilename of "exportedData.csv", Smart GWT Server would export to file $webRoot/shared/ds/exportedData.csv.

  If you do not specify this property, Smart GWT Server will export to the file indicated by exportFilename directly in the default export location.

  This property is only applicable when exportToFilesystem is set.

  Returns:

  Current exportPath value. Default value is null

  See Also:

  getExportFilename()

• setExportPropertyIdentifier

  public DSRequest setExportPropertyIdentifier(PropertyIdentifier exportPropertyIdentifier)

  Determines the PropertyIdentifier to be used in the exported data. This essentially means, should we export internal field names like "countryCode" or "EMPLOYEE_NO", or localized descriptive field titles like "code du pays" or "Employee Number". This setting has a lot in common with exportRawValues; both are largely dependent on whether the exported data is intended for direct consumption by an end user (in which case it is appropriate to export formatted values and localized field titles), or for interface to some downstream computer system (in which case you probably want raw, unformatted values and internal field names).

  If this property is not set, the following defaults apply:

  • If the export format is a native spreadsheet format (XLS or OOXML), localized field titles are used
  • If the export format is CSV, XML or JSON and this is a client-driven export (ie it was initiated by a call to exportClientData()), localized field titles are used
  • If the export format is CSV, XML or JSON and this is not a client-driven export, internal field names are used

  Parameters:

  exportPropertyIdentifier - New exportPropertyIdentifier value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  Exports & Formatting

• getExportPropertyIdentifier

  public PropertyIdentifier getExportPropertyIdentifier()

  Determines the PropertyIdentifier to be used in the exported data. This essentially means, should we export internal field names like "countryCode" or "EMPLOYEE_NO", or localized descriptive field titles like "code du pays" or "Employee Number". This setting has a lot in common with exportRawValues; both are largely dependent on whether the exported data is intended for direct consumption by an end user (in which case it is appropriate to export formatted values and localized field titles), or for interface to some downstream computer system (in which case you probably want raw, unformatted values and internal field names).

  If this property is not set, the following defaults apply:

  • If the export format is a native spreadsheet format (XLS or OOXML), localized field titles are used
  • If the export format is CSV, XML or JSON and this is a client-driven export (ie it was initiated by a call to exportClientData()), localized field titles are used
  • If the export format is CSV, XML or JSON and this is not a client-driven export, internal field names are used

  Returns:

  Current exportPropertyIdentifier value. Default value is null

  See Also:

  Exports & Formatting

• setExportRawValues

  public DSRequest setExportRawValues(java.lang.Boolean exportRawValues)

  Whether formatting settings should be applied to data being exported. Default behavior and the effect of setting of exportRawValues is described in the Export Formatting overview.

  Parameters:

  exportRawValues - New exportRawValues value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  Exports & Formatting

• getExportRawValues

  public java.lang.Boolean getExportRawValues()

  Whether formatting settings should be applied to data being exported. Default behavior and the effect of setting of exportRawValues is described in the Export Formatting overview.

  Returns:

  Current exportRawValues value. Default value is null

  See Also:

  Exports & Formatting

• setExportResults

  public DSRequest setExportResults(java.lang.Boolean exportResults)

  When set, causes the results of the DSRequest to be exported to a file, whose name and format are indicated by exportFilename and exportAs respectively. When no exportFilename is provided, the default is Results.csv and the default value of exportAs is csv.

  The export field-list can also be configured, see exportFields. Formats for exported date and numeric are controlled by several settings - see ExportFormatting for an overview.

  Once the operation completes, exportDisplay specifies whether the exported data should be downloaded to the file-system or displayed in a new window. The default value of exportDisplay is "download" which displays the Save As dialog. See ExportDisplay for more information.

  You can configure the style of line-breaks to use when generating the output, the delimiter to use when exporting to CSV and the separator-character to use in field-titles when exporting to XML.

  Additionally, you can output arbitrary text before and after the exported data by setting exportHeader and exportFooter.

  Note that for security reasons, an export initiated using dsRequest properties does not provide support for JSON format (see this post for more detail). However, you can use operationBinding.exportAs:"json" in a server-side .ds.xml file to force JSON export to be allowed.

  As well as setting dsRequest.exportResults and related properties, exports can be initiated in two other ways, via OperationBindings and via custom server code which sets export-related properties on the DSResponse. Both of those methods support exporting to JSON format.

  Format Examples XML format

        <List>
            <Object>
                <id>10101</id>
                <displayName>Record 10101</displayName>
            </Object>
       </List>
    

  JSON Format

        [
            { id: 10101, displayName: "Record 10101" }
        ]
    

  CSV Format

        id,displayName
        10101,"Record 10101"
    

  Parameters:

  exportResults - New exportResults value. Default value is false

  Returns:

  DSRequest instance, for chaining setter calls

• getExportResults

  public java.lang.Boolean getExportResults()

  When set, causes the results of the DSRequest to be exported to a file, whose name and format are indicated by exportFilename and exportAs respectively. When no exportFilename is provided, the default is Results.csv and the default value of exportAs is csv.

  The export field-list can also be configured, see exportFields. Formats for exported date and numeric are controlled by several settings - see ExportFormatting for an overview.

  Once the operation completes, exportDisplay specifies whether the exported data should be downloaded to the file-system or displayed in a new window. The default value of exportDisplay is "download" which displays the Save As dialog. See ExportDisplay for more information.

  You can configure the style of line-breaks to use when generating the output, the delimiter to use when exporting to CSV and the separator-character to use in field-titles when exporting to XML.

  Additionally, you can output arbitrary text before and after the exported data by setting exportHeader and exportFooter.

  Note that for security reasons, an export initiated using dsRequest properties does not provide support for JSON format (see this post for more detail). However, you can use operationBinding.exportAs:"json" in a server-side .ds.xml file to force JSON export to be allowed.

  As well as setting dsRequest.exportResults and related properties, exports can be initiated in two other ways, via OperationBindings and via custom server code which sets export-related properties on the DSResponse. Both of those methods support exporting to JSON format.

  Format Examples XML format

        <List>
            <Object>
                <id>10101</id>
                <displayName>Record 10101</displayName>
            </Object>
       </List>
    

  JSON Format

        [
            { id: 10101, displayName: "Record 10101" }
        ]
    

  CSV Format

        id,displayName
        10101,"Record 10101"
    

  Returns:

  Current exportResults value. Default value is false

• setExportShowHeaderSpanTitles

  public DSRequest setExportShowHeaderSpanTitles(java.lang.Boolean exportShowHeaderSpanTitles)

  When you erxport a ListGrid that has headerSpans, should headerSpans also be exported. See exportSpanTitleSeparator for details of of what it means to export headerSpans to different export targets.

  Note that exportPropertyIdentifier controls whether field names or titles are appended to the headerSpan titles (and used for fields without headerSpans).

  Parameters:

  exportShowHeaderSpanTitles - New exportShowHeaderSpanTitles value. Default value is true

  Returns:

  DSRequest instance, for chaining setter calls

• getExportShowHeaderSpanTitles

  public java.lang.Boolean getExportShowHeaderSpanTitles()

  When you erxport a ListGrid that has headerSpans, should headerSpans also be exported. See exportSpanTitleSeparator for details of of what it means to export headerSpans to different export targets.

  Note that exportPropertyIdentifier controls whether field names or titles are appended to the headerSpan titles (and used for fields without headerSpans).

  Returns:

  Current exportShowHeaderSpanTitles value. Default value is true

• setExportSpanTitleSeparator

  public DSRequest setExportSpanTitleSeparator(java.lang.String exportSpanTitleSeparator)

  When you export a ListGrid that has headerSpans defined and exportShowHeaderSpanTitles is true, the behavior is dependent on the export type. Direct exports to Excel formats (both XLS and OOXML) place the headerSpans in merged cells in the spreadsheet, giving the same visual effect as the original ListGrid. This is not possible with exports to CSV format; instead, we alter the exported headers so that they contain the titles of the ancestor headerSpan(s).

  For example, if you had a field titled "Population" inside a headerSpan titled "National", nested inside another headerSpan titled "Demographics", that would result in the exported field being titled "Demographics - National - Population".

  The exportSpanTitleSeparator property allows you to override the separator string used when constructing these amalgamated headers.

  Parameters:

  exportSpanTitleSeparator - New exportSpanTitleSeparator value. Default value is " - "

  Returns:

  DSRequest instance, for chaining setter calls

• getExportSpanTitleSeparator

  public java.lang.String getExportSpanTitleSeparator()

  When you export a ListGrid that has headerSpans defined and exportShowHeaderSpanTitles is true, the behavior is dependent on the export type. Direct exports to Excel formats (both XLS and OOXML) place the headerSpans in merged cells in the spreadsheet, giving the same visual effect as the original ListGrid. This is not possible with exports to CSV format; instead, we alter the exported headers so that they contain the titles of the ancestor headerSpan(s).

  For example, if you had a field titled "Population" inside a headerSpan titled "National", nested inside another headerSpan titled "Demographics", that would result in the exported field being titled "Demographics - National - Population".

  The exportSpanTitleSeparator property allows you to override the separator string used when constructing these amalgamated headers.

  Returns:

  Current exportSpanTitleSeparator value. Default value is " - "

• setExportStreaming

  public DSRequest setExportStreaming(boolean exportStreaming)

  When exporting to OOXML format (this is the standard file format used by Excel 2007 and later), we default to using streaming mode, for memory efficiency. You can override this for individual exports by setting this flag false. You may wish to do this if you need to grab the spreadsheet object in a DMI and do something with it. The underlying object in use - POI's SXSSFWorkbook - is intended for write only and cannot usefully be read.

  You can switch off Excel streaming altogether by setting "excel.useStreaming" false in server.properties.

  Note, OOXML is the only native Excel format that supports streaming: when exporting to the older XLS format, we build the spreadsheet in its entirety in server-side memory before writing it to disk or returning it to the client. This is unlikely to change: streaming the XLS format is impractical bcause it is a self-referential binary format, and in any case the problem of huge exports overflowing JVM memory is less likely to arise with XLS, because it is innately limited to 65535 rows.

  Parameters:

  exportStreaming - New exportStreaming value. Default value is true

  Returns:

  DSRequest instance, for chaining setter calls

• getExportStreaming

  public boolean getExportStreaming()

  When exporting to OOXML format (this is the standard file format used by Excel 2007 and later), we default to using streaming mode, for memory efficiency. You can override this for individual exports by setting this flag false. You may wish to do this if you need to grab the spreadsheet object in a DMI and do something with it. The underlying object in use - POI's SXSSFWorkbook - is intended for write only and cannot usefully be read.

  You can switch off Excel streaming altogether by setting "excel.useStreaming" false in server.properties.

  Note, OOXML is the only native Excel format that supports streaming: when exporting to the older XLS format, we build the spreadsheet in its entirety in server-side memory before writing it to disk or returning it to the client. This is unlikely to change: streaming the XLS format is impractical bcause it is a self-referential binary format, and in any case the problem of huge exports overflowing JVM memory is less likely to arise with XLS, because it is innately limited to 65535 rows.

  Returns:

  Current exportStreaming value. Default value is true

• setExportTitleSeparatorChar

  public DSRequest setExportTitleSeparatorChar(java.lang.String exportTitleSeparatorChar)

  The character with which to replace spaces in field-titles when exporting to XML. If not specified in the request, the server uses "".

  Parameters:

  exportTitleSeparatorChar - New exportTitleSeparatorChar value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getExportTitleSeparatorChar

  public java.lang.String getExportTitleSeparatorChar()

  The character with which to replace spaces in field-titles when exporting to XML. If not specified in the request, the server uses "".

  Returns:

  Current exportTitleSeparatorChar value. Default value is null

• setExportToClient

  public DSRequest setExportToClient(java.lang.Boolean exportToClient)

  If set to true (the default), Smart GWT Server will export data back to the client, either as a file download or as content in a new browser window, depending on the setting of exportDisplay.

  Setting this property to false disables this. This may be useful when developers wish to export the data to a file on the server fileSystem, but do not need to display it in the browser in response to the export request.

  Note that it is perfectly valid to have both this property and exportToFilesystem set to true; in this case the data is both exported to a file on the server filesystem, and downloaded to the client. If you specify neither property, the export no-ops.

  Parameters:

  exportToClient - New exportToClient value. Default value is true

  Returns:

  DSRequest instance, for chaining setter calls

• getExportToClient

  public java.lang.Boolean getExportToClient()

  If set to true (the default), Smart GWT Server will export data back to the client, either as a file download or as content in a new browser window, depending on the setting of exportDisplay.

  Setting this property to false disables this. This may be useful when developers wish to export the data to a file on the server fileSystem, but do not need to display it in the browser in response to the export request.

  Note that it is perfectly valid to have both this property and exportToFilesystem set to true; in this case the data is both exported to a file on the server filesystem, and downloaded to the client. If you specify neither property, the export no-ops.

  Returns:

  Current exportToClient value. Default value is true

• setExportToFilesystem

  public DSRequest setExportToFilesystem(java.lang.Boolean exportToFilesystem)

  If set, Smart GWT Server will export data to a file on the server filesystem. The file we export to is determined by the exportFilename and exportPath. Note that filesystem exports are disabled by default, for security reasons. To enable them, set export.allow.filesystem to true in your server.properties file. If you enable filesystem exports, you should also consider setting a default export path, as described in the exportPath documentation.

  Note that it is perfectly valid to specify both this property and exportToClient; in this case the data is both exported to a file on the server filesystem and downloaded to the client. If you specify neither property, the export no-ops.

  It is possible to redirect the filesystem export to make use of an OutputStream you provide. You use this when you want to make some use of the export document other than writing it to a disk file - for example, attaching it to an email or writing it to a database table. See the server-side Javadocs for DSRequest.setExportTo().

  Parameters:

  exportToFilesystem - New exportToFilesystem value. Default value is false

  Returns:

  DSRequest instance, for chaining setter calls

• getExportToFilesystem

  public java.lang.Boolean getExportToFilesystem()

  If set, Smart GWT Server will export data to a file on the server filesystem. The file we export to is determined by the exportFilename and exportPath. Note that filesystem exports are disabled by default, for security reasons. To enable them, set export.allow.filesystem to true in your server.properties file. If you enable filesystem exports, you should also consider setting a default export path, as described in the exportPath documentation.

  Note that it is perfectly valid to specify both this property and exportToClient; in this case the data is both exported to a file on the server filesystem and downloaded to the client. If you specify neither property, the export no-ops.

  It is possible to redirect the filesystem export to make use of an OutputStream you provide. You use this when you want to make some use of the export document other than writing it to a disk file - for example, attaching it to an email or writing it to a database table. See the server-side Javadocs for DSRequest.setExportTo().

  Returns:

  Current exportToFilesystem value. Default value is false

• setExportTZ

  public DSRequest setExportTZ(java.lang.String exportTZ)

  For server-side export with ExportFormat "xls" or "ooxml" only, timezone to use when saving values from FieldType "datetime" to the spreadsheet.

  This setting exists because MS Excel™ has no concept of providing a true datetime value that is timezone-independent and will display in the local timezone where the Excel program is launched. This setting sets the timezone of the Excel workbook, so that it will display dates in the same timezone regardless of the local timezone where the Excel program is launched. Alternative approach is to set exportDatesAsFormattedString=true telling datetime values must be provided as a rendered string, which implies rendering in a particular timezone when the spreadsheet is generated.

  exportTZ can either be specified as a timezone offset in the same format expected by String (for example, "+01:00" for one hour after GMT) or as the special constants "client" (meaning the current client display timezone) or "server" (meaning the timezone of the server).

  Default if unspecified is "server".

  This setting does not affect fields of type "date" or "time", which are timezone-independent values. See DateFormatAndStorage for more information on how Smart GWT handles date, time and datetime values.

  All non-spreadsheet export formats always use UTC. This setting also does not affect client-driven exports (DataSource.exportClientData()), which always use client-side time.

  Parameters:

  exportTZ - New exportTZ value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  Exports & Formatting

• getExportTZ

  public java.lang.String getExportTZ()

  For server-side export with ExportFormat "xls" or "ooxml" only, timezone to use when saving values from FieldType "datetime" to the spreadsheet.

  This setting exists because MS Excel™ has no concept of providing a true datetime value that is timezone-independent and will display in the local timezone where the Excel program is launched. This setting sets the timezone of the Excel workbook, so that it will display dates in the same timezone regardless of the local timezone where the Excel program is launched. Alternative approach is to set exportDatesAsFormattedString=true telling datetime values must be provided as a rendered string, which implies rendering in a particular timezone when the spreadsheet is generated.

  exportTZ can either be specified as a timezone offset in the same format expected by String (for example, "+01:00" for one hour after GMT) or as the special constants "client" (meaning the current client display timezone) or "server" (meaning the timezone of the server).

  Default if unspecified is "server".

  This setting does not affect fields of type "date" or "time", which are timezone-independent values. See DateFormatAndStorage for more information on how Smart GWT handles date, time and datetime values.

  All non-spreadsheet export formats always use UTC. This setting also does not affect client-driven exports (DataSource.exportClientData()), which always use client-side time.

  Returns:

  Current exportTZ value. Default value is null

  See Also:

  Exports & Formatting

• setExportValueFields

  public DSRequest setExportValueFields(java.lang.Boolean exportValueFields)

  This flag has a different meaning depending on whether you are doing a client-driven or server-driven export.

  For exportClientData() calls (client-driven), ordinarily any fields that have a displayField defined have the value of that displayField exported, rather than the underlying value in the valueField. If you set the exportValueFields property, we export both the underlying value and the displayField value.

  Again for exportClientData() calls, any fields that have a valueMap defined ordinarily have the mapped value of the field exported, rather than the underlying data value. If you set the exportValueFields property, we instead export the underlying data value. Note, there is only one field in this scenario, not a valueField and a separate displayField, so we export either the underlying data value or the mapped value, not both as in the displayField/valueField case described above.

  For exportData() calls (server-driven), we ordinarily export the underlying data value of all fields. However, if you set the exportValueFields property explicitly to false, any fields that have a DataSource-defined valueMap will have the mapped value exported instead. This is similar to the client-side treatment of valueMaps, except that the defaults are reversed.

  For exportData() calls, if we encounter a field that has an in-record displayField declared in the DataSource, by default we export both the underlying value and the display value, so you end up with two columns in the exported data for that field. You can influence this by setting exportValueFields explicitly: if set true we export only the value field, and if set false we export only the display field. Note, the reason for the similar but not identical behavior of this flag between exportData() and exportClientData() is backwards compatibility.

  Parameters:

  exportValueFields - New exportValueFields value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getExportValueFields

  public java.lang.Boolean getExportValueFields()

  This flag has a different meaning depending on whether you are doing a client-driven or server-driven export.

  For exportClientData() calls (client-driven), ordinarily any fields that have a displayField defined have the value of that displayField exported, rather than the underlying value in the valueField. If you set the exportValueFields property, we export both the underlying value and the displayField value.

  Again for exportClientData() calls, any fields that have a valueMap defined ordinarily have the mapped value of the field exported, rather than the underlying data value. If you set the exportValueFields property, we instead export the underlying data value. Note, there is only one field in this scenario, not a valueField and a separate displayField, so we export either the underlying data value or the mapped value, not both as in the displayField/valueField case described above.

  For exportData() calls (server-driven), we ordinarily export the underlying data value of all fields. However, if you set the exportValueFields property explicitly to false, any fields that have a DataSource-defined valueMap will have the mapped value exported instead. This is similar to the client-side treatment of valueMaps, except that the defaults are reversed.

  For exportData() calls, if we encounter a field that has an in-record displayField declared in the DataSource, by default we export both the underlying value and the display value, so you end up with two columns in the exported data for that field. You can influence this by setting exportValueFields explicitly: if set true we export only the value field, and if set false we export only the display field. Note, the reason for the similar but not identical behavior of this flag between exportData() and exportClientData() is backwards compatibility.

  Returns:

  Current exportValueFields value. Default value is null

• setFieldValueExpressions

  public DSRequest setFieldValueExpressions(java.util.Map fieldValueExpressions)

  A set of key:value pairs, mapping field names to expressions that will be evaluated server-side to derive a value for that field. This property allows for client-driven Transaction Chaining, with some restrictions for security reasons:

  • Normal server-side Transaction Chaining settings for a field take precedence over this property, so server-defined rules cannot be overridden from the client
  • Arbitrary Velocity expressions are not allowed in DSRequests sent from the client (fieldValueExpressions is also a valid property on a server-side DSRequest, and normal Velocity expressions are allowed in that case - see the server-side Javadoc for DSRequest.setFieldValueExpressions()). For client-originated requests, only the following bindings are allowed - see the Velocity overview for details of what these values mean:
    • $currentDate
    • $currentDateUTC
    • $transactionDate
    • $transactionDateUTC
    • $userId
    • $masterId - see DSRequestModifier.value for details
    • References to specific fields in prior responses, via $responseData.first and $responseData.last, with or without parameters. For example, $responseData.first("myDataSource", "fetch")[0].myField. See the Velocity overview for details of $responseData
    • References to certain metadata properties of prior responses, via $responses.first and $responses.last, with or without parameters. For example, $responses.last("myDataSource", "fetch").totalRows. Note that the only properties allowed in a client-driven fieldValueExpression are: "startRow", "endRow", "totalRows" and "status"; this restriction does not apply to server-driven fieldValueExpressions. See the Velocity overview for details of $responses
  • Normal declarative security rules apply: if a field is not valid for writing, its fieldValueExpression will be ignored. Again, this only applies to client-originated requests.

  Note, it is possible to globally disable fieldValueExpression in client-originated requests by setting a flag in your server.properties file:

     dataSource.allowClientFieldValueExpressions: false

  Parameters:

  fieldValueExpressions - New fieldValueExpressions value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  Transaction Chaining

• getFieldValueExpressions

  public java.util.Map getFieldValueExpressions()

  A set of key:value pairs, mapping field names to expressions that will be evaluated server-side to derive a value for that field. This property allows for client-driven Transaction Chaining, with some restrictions for security reasons:

  • Normal server-side Transaction Chaining settings for a field take precedence over this property, so server-defined rules cannot be overridden from the client
  • Arbitrary Velocity expressions are not allowed in DSRequests sent from the client (fieldValueExpressions is also a valid property on a server-side DSRequest, and normal Velocity expressions are allowed in that case - see the server-side Javadoc for DSRequest.setFieldValueExpressions()). For client-originated requests, only the following bindings are allowed - see the Velocity overview for details of what these values mean:
    • $currentDate
    • $currentDateUTC
    • $transactionDate
    • $transactionDateUTC
    • $userId
    • $masterId - see DSRequestModifier.value for details
    • References to specific fields in prior responses, via $responseData.first and $responseData.last, with or without parameters. For example, $responseData.first("myDataSource", "fetch")[0].myField. See the Velocity overview for details of $responseData
    • References to certain metadata properties of prior responses, via $responses.first and $responses.last, with or without parameters. For example, $responses.last("myDataSource", "fetch").totalRows. Note that the only properties allowed in a client-driven fieldValueExpression are: "startRow", "endRow", "totalRows" and "status"; this restriction does not apply to server-driven fieldValueExpressions. See the Velocity overview for details of $responses
  • Normal declarative security rules apply: if a field is not valid for writing, its fieldValueExpression will be ignored. Again, this only applies to client-originated requests.

  Note, it is possible to globally disable fieldValueExpression in client-originated requests by setting a flag in your server.properties file:

     dataSource.allowClientFieldValueExpressions: false

  Returns:

  Current fieldValueExpressions value. Default value is null

  See Also:

  Transaction Chaining

• setGenerateRelatedUpdates

  public DSRequest setGenerateRelatedUpdates(java.lang.Boolean generateRelatedUpdates)

  Specifies should related updates have to be generated. If not set (or set to null) then related updates will be generated only for "add" and "update" operations. This property has to be explicitly set to true to generate related updates for "remove" operation.

  This functionality loads related objects from database thus affecting operation performance. For "add" and "update" operations related objects are loaded anyway and performance impact is minimal. Simple "remove" operation does not need to load related objects. Depending on database structure performance impact can be significant if this property is set to true.

  Note this feature works only with Hibernate/JPA data sources, see JPA & Hibernate Relations for instructions how to set up relations. Table below uses "country -> cities" sample data model.

  Relation and Operation type	Loading complete related objects	Loading related IDs
  Many-to-one (cities -> country): ADD/UPDATE	If operation affected country, for example new city added with existing countryId, then relatedUpdate is generated. Otherwise if city is added or updated without countryId set, relatedUpdate is not generated. Note that if provided countryId does not exist, it is created.	Same as with complete related objects, except if provided countryId does not exist, then it is not created, but reset to NULL.
  Many-to-one (cities -> country): REMOVE	Removes record, depending on setting generates or not relatedUpdate for parent record. For example if city record is removed and countryId is sent to the server in remove request, then country record will be generated in relatedUpdates.
  One-to-many (country -> cities): ADD/UPDATE	If add or update operation provides value sets for cities as well as for country, then cities are created/updated if necessary and relatedUpdates are generated. Note that all fields in cities value sets can be sent to server.	Same as with complete related objects, except you can only sent primary key values for cities.
  One-to-many (country -> cities): REMOVE	Removes country, depending on setting returns or not relatedUpdates for the cities of removed country, which can be either REMOVE operations of all cities if cascade enabled, or UPDATE operations setting countryId=null to all cities if cascade is disabled

  Note that Many-to-Many works the same way as One-to-Many.

  Parameters:

  generateRelatedUpdates - New generateRelatedUpdates value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getGenerateRelatedUpdates

  public java.lang.Boolean getGenerateRelatedUpdates()

  Specifies should related updates have to be generated. If not set (or set to null) then related updates will be generated only for "add" and "update" operations. This property has to be explicitly set to true to generate related updates for "remove" operation.

  This functionality loads related objects from database thus affecting operation performance. For "add" and "update" operations related objects are loaded anyway and performance impact is minimal. Simple "remove" operation does not need to load related objects. Depending on database structure performance impact can be significant if this property is set to true.

  Note this feature works only with Hibernate/JPA data sources, see JPA & Hibernate Relations for instructions how to set up relations. Table below uses "country -> cities" sample data model.

  Relation and Operation type	Loading complete related objects	Loading related IDs
  Many-to-one (cities -> country): ADD/UPDATE	If operation affected country, for example new city added with existing countryId, then relatedUpdate is generated. Otherwise if city is added or updated without countryId set, relatedUpdate is not generated. Note that if provided countryId does not exist, it is created.	Same as with complete related objects, except if provided countryId does not exist, then it is not created, but reset to NULL.
  Many-to-one (cities -> country): REMOVE	Removes record, depending on setting generates or not relatedUpdate for parent record. For example if city record is removed and countryId is sent to the server in remove request, then country record will be generated in relatedUpdates.
  One-to-many (country -> cities): ADD/UPDATE	If add or update operation provides value sets for cities as well as for country, then cities are created/updated if necessary and relatedUpdates are generated. Note that all fields in cities value sets can be sent to server.	Same as with complete related objects, except you can only sent primary key values for cities.
  One-to-many (country -> cities): REMOVE	Removes country, depending on setting returns or not relatedUpdates for the cities of removed country, which can be either REMOVE operations of all cities if cascade enabled, or UPDATE operations setting countryId=null to all cities if cascade is disabled

  Note that Many-to-Many works the same way as One-to-Many.

  Returns:

  Current generateRelatedUpdates value. Default value is null

• setGroupBy

  public DSRequest setGroupBy(java.lang.String... groupBy)

  List of fields to group by when using server-side summarization.

  Valid only for an operation of type "fetch". See the Server Summaries overview for details and examples of usage.

  Parameters:

  groupBy - New groupBy value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  setSummaryFunctions(java.util.Map<java.lang.String, com.smartgwt.client.types.SummaryFunctionType>), Server Summaries

• getGroupBy

  public java.lang.String[] getGroupBy()

  List of fields to group by when using server-side summarization.

  Valid only for an operation of type "fetch". See the Server Summaries overview for details and examples of usage.

  Returns:

  Current groupBy value. Default value is null

  See Also:

  getSummaryFunctions(), Server Summaries

• setHeaderData

  public DSRequest setHeaderData(java.util.Map headerData)

  For DataSources using SOAP messaging with a WSDL web service, data to be serialized to form SOAP headers, as a map from the header part name to the data. See WSRequest.headerData for more information.

  SOAP headers typically contain request metadata such as a session id for authentication, and so dsRequest.headerData is typically populated by DataSource.transformRequest(), or, for data that applies to every request sent to the server, by WebService.getHeaderData().

  Note that this only applies to SOAP headers. General HTTP headers for requests may be modified using RPCRequest.httpHeaders.

  Parameters:

  headerData - New headerData value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getHeaderData

  public java.util.Map getHeaderData()

  For DataSources using SOAP messaging with a WSDL web service, data to be serialized to form SOAP headers, as a map from the header part name to the data. See WSRequest.headerData for more information.

  SOAP headers typically contain request metadata such as a session id for authentication, and so dsRequest.headerData is typically populated by DataSource.transformRequest(), or, for data that applies to every request sent to the server, by WebService.getHeaderData().

  Note that this only applies to SOAP headers. General HTTP headers for requests may be modified using RPCRequest.httpHeaders.

  Returns:

  Current headerData value. Default value is null

• setKeepParentsOnFilter

  public DSRequest setKeepParentsOnFilter(java.lang.Boolean keepParentsOnFilter)

  This property is for advanced use in integrating trees that load data on demand using data paging. When this flag is set, a server fetch operation is expected to return all of the tree nodes that either match the provided criteria or have one or more children that match the criteria.

  A ResultTree with fetchMode:"paged" and with keepParentsOnFilter enabled will automatically set this property to true on all DSRequests that it sends to the server.

  Currently, no built-in server-side connectors (SQL, JPA, Hibernate) implement support for the keepParentsOnFilter flag.

  Parameters:

  keepParentsOnFilter - New keepParentsOnFilter value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  Tree DataBinding

• getKeepParentsOnFilter

  public java.lang.Boolean getKeepParentsOnFilter()

  This property is for advanced use in integrating trees that load data on demand using data paging. When this flag is set, a server fetch operation is expected to return all of the tree nodes that either match the provided criteria or have one or more children that match the criteria.

  A ResultTree with fetchMode:"paged" and with keepParentsOnFilter enabled will automatically set this property to true on all DSRequests that it sends to the server.

  Currently, no built-in server-side connectors (SQL, JPA, Hibernate) implement support for the keepParentsOnFilter flag.

  Returns:

  Current keepParentsOnFilter value. Default value is null

  See Also:

  Tree DataBinding

• setLineBreakStyle

  public DSRequest setLineBreakStyle(java.lang.String lineBreakStyle)

  The style of line-breaks to use in the exported output. See LineBreakStyle for more information.

  Parameters:

  lineBreakStyle - New lineBreakStyle value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getLineBreakStyle

  public java.lang.String getLineBreakStyle()

  The style of line-breaks to use in the exported output. See LineBreakStyle for more information.

  Returns:

  Current lineBreakStyle value. Default value is null

• setLinkDataFetchOperation

  public DSRequest setLinkDataFetchOperation(java.lang.String linkDataFetchOperation)

  For a databound multi-link tree, this is the operationId to use for the separate fetch on the ResultTree.linkDataSource that will be generated if LinkDataFetchMode is "separate". This property overrides the linkDataFetchOperation property on ResultTree, for this fetch only.

  Ignored if this DSRequest is not a fetch against a multi-link tree.

  Parameters:

  linkDataFetchOperation - New linkDataFetchOperation value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getLinkDataFetchOperation

  public java.lang.String getLinkDataFetchOperation()

  For a databound multi-link tree, this is the operationId to use for the separate fetch on the ResultTree.linkDataSource that will be generated if LinkDataFetchMode is "separate". This property overrides the linkDataFetchOperation property on ResultTree, for this fetch only.

  Ignored if this DSRequest is not a fetch against a multi-link tree.

  Returns:

  Current linkDataFetchOperation value. Default value is null

• setOldValues

  public DSRequest setOldValues(Record oldValues)

  For an update or remove operation, the original values from the record that is being updated or removed. oldValues is automatically added to DSRequests submitted by DataBound Components. Available on the server via DSRequest.getOldValues().

  The server can compare the oldValues to the most recent stored values in order to detect that the user was looking at stale values when the user submitted changes (NOTE: this means of detecting concurrent edit is sometimes called "optimistic concurrency" or "long transactions").

  In applications where a policy of "last update wins" is not appropriate when updating certain fields, special UI can be shown for this case. For example, on detecting concurrent edit, the server may send back a special dsResponse.status code that the client application detects, offering the user a choice of proceeding with the operation, discarding edits, or reconciling new and old values in a special interface.

  See the ConcurrentEdits overview for more on handling concurrent edits in Smart GWT DataSources.

  Parameters:

  oldValues - New oldValues value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getOldValues

  public Record getOldValues()

  For an update or remove operation, the original values from the record that is being updated or removed. oldValues is automatically added to DSRequests submitted by DataBound Components. Available on the server via DSRequest.getOldValues().

  The server can compare the oldValues to the most recent stored values in order to detect that the user was looking at stale values when the user submitted changes (NOTE: this means of detecting concurrent edit is sometimes called "optimistic concurrency" or "long transactions").

  In applications where a policy of "last update wins" is not appropriate when updating certain fields, special UI can be shown for this case. For example, on detecting concurrent edit, the server may send back a special dsResponse.status code that the client application detects, offering the user a choice of proceeding with the operation, discarding edits, or reconciling new and old values in a special interface.

  See the ConcurrentEdits overview for more on handling concurrent edits in Smart GWT DataSources.

  Returns:

  Current oldValues value. Default value is null

• setOperationId

  public DSRequest setOperationId(java.lang.String operationId)

  When a DataBoundComponent sends a DSRequest, the dsRequest.operationId will be automatically picked up from the fetchOperation, addOperation, etc properties of the DataBoundComponent.

  The operationId serves as an identifier that you can use to create variations on the 4 basic DataSource operations that are used by different components in different parts of your application. For example, you may be using a standard fetch operation in one part of your application, however on another screen you want to perform a fetch operation on the same DataSource but interpret search criteria differently (eg full text search).

  If you declare more than one OperationBinding for the same OperationBinding.operationType, you can specify an operationId on the operationBinding which will cause that operationBinding to be used for dsRequests containing a matching operationId. This allows all the possible settings of an operationBinding, including wsOperation or DMI settings, to be switched on a per-component or per-request basis.

  For example, by setting the fetchOperation on a particular ListGrid, you could cause it to invoke a different server method via DMI, different dataURL or different web service operation.

  The operationId can also be directly received by the server in order to affect behavior. When using the Smart GWT Server, operationId can be accessed via dsRequest.getOperationId(). The RestDataSource will also send the operationId to the server as part of the request metadata.

  Note that if you manually invoke a DataSource operation, you can also specify operationId via the requestProperties parameter.

  Note that the operationId has special significance in terms of whether two DSRequests are considered equivalent for caching and synchronization purposes - see DsRequestEquivalence.

  Parameters:

  operationId - New operationId value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  Operations Overview

• getOperationId

  public java.lang.String getOperationId()

  When a DataBoundComponent sends a DSRequest, the dsRequest.operationId will be automatically picked up from the fetchOperation, addOperation, etc properties of the DataBoundComponent.

  The operationId serves as an identifier that you can use to create variations on the 4 basic DataSource operations that are used by different components in different parts of your application. For example, you may be using a standard fetch operation in one part of your application, however on another screen you want to perform a fetch operation on the same DataSource but interpret search criteria differently (eg full text search).

  If you declare more than one OperationBinding for the same OperationBinding.operationType, you can specify an operationId on the operationBinding which will cause that operationBinding to be used for dsRequests containing a matching operationId. This allows all the possible settings of an operationBinding, including wsOperation or DMI settings, to be switched on a per-component or per-request basis.

  For example, by setting the fetchOperation on a particular ListGrid, you could cause it to invoke a different server method via DMI, different dataURL or different web service operation.

  The operationId can also be directly received by the server in order to affect behavior. When using the Smart GWT Server, operationId can be accessed via dsRequest.getOperationId(). The RestDataSource will also send the operationId to the server as part of the request metadata.

  Note that if you manually invoke a DataSource operation, you can also specify operationId via the requestProperties parameter.

  Note that the operationId has special significance in terms of whether two DSRequests are considered equivalent for caching and synchronization purposes - see DsRequestEquivalence.

  Returns:

  Current operationId value. Default value is null

  See Also:

  Operations Overview

• setOperationType

  public DSRequest setOperationType(DSOperationType operationType)

  Type of operation being performed: "fetch", "add", "remove", "update" or "custom".

  This property is generally automatically populated, for example when calling fetchData() on a DataSource or DataBound component the operationType is automatically set to "fetch". Note that "custom" operations are never generated automatically, they are always fired by your code.

  Parameters:

  operationType - New operationType value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getOperationType

  public DSOperationType getOperationType()

  Type of operation being performed: "fetch", "add", "remove", "update" or "custom".

  This property is generally automatically populated, for example when calling fetchData() on a DataSource or DataBound component the operationType is automatically set to "fetch". Note that "custom" operations are never generated automatically, they are always fired by your code.

  Returns:

  Current operationType value. Default value is null

• setOutputs

  public DSRequest setOutputs(java.lang.String outputs)

  The list of fields to return in the response, specified as a comma-separated string (eg, "foo, bar, baz"). You can use this property to indicate to the server that you are only interested in a subset of the fields that would normally be returned.

  Note that you cannot use this property to request a superset of the fields that would normally be returned, because that would be a security hole. It is possible to configure individual OperationBindings to return extra fields, but this must be done in the server's DataSource descriptor; it cannot be altered on the fly from the client side.

  Also, this setting is overridden by the DataSourceField.outputWhen setting, meaning that if a field is listed in request.outputs, but does not match the type of condition of outputWhen setting, it won't be returned to the client.

  Further, this setting is overridden by the ListGrid.fetchFields setting, which will include all visible fields along with any fields it specifies.

  Parameters:

  outputs - New outputs value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  OperationBinding.outputs, setAdditionalOutputs(java.lang.String), DataSourceField.outputWhen

• getOutputs

  public java.lang.String getOutputs()

  The list of fields to return in the response, specified as a comma-separated string (eg, "foo, bar, baz"). You can use this property to indicate to the server that you are only interested in a subset of the fields that would normally be returned.

  Note that you cannot use this property to request a superset of the fields that would normally be returned, because that would be a security hole. It is possible to configure individual OperationBindings to return extra fields, but this must be done in the server's DataSource descriptor; it cannot be altered on the fly from the client side.

  Also, this setting is overridden by the DataSourceField.outputWhen setting, meaning that if a field is listed in request.outputs, but does not match the type of condition of outputWhen setting, it won't be returned to the client.

  Further, this setting is overridden by the ListGrid.fetchFields setting, which will include all visible fields along with any fields it specifies.

  Returns:

  Current outputs value. Default value is null

  See Also:

  OperationBinding.outputs, getAdditionalOutputs(), DataSourceField.outputWhen

• getParentNode

  public TreeNode getParentNode()

  For advanced use in integrating trees that load data on demand with web services, parentNode is automatically set in "fetch" DSRequests issued by a databound TreeGrid that is loading children for that parentNode.

  This is sometimes needed if a web service requires that additional properties beyond the ID of the parentNode must be passed in order to accomplished level-by-level loading. A custom implementation of DataSource.transformRequest() can access dsRequest.parentNode and add any such properties to data.

  parentNode will also be automatically set by a TreeGrid performing databound reparenting of nodes, as implemented by TreeGrid.folderDrop().

  This property can only be read. There is no meaning to setting this property yourself.

  Returns:

  Current parentNode value. Default value is null

• setPendingAdd

  public DSRequest setPendingAdd(java.lang.Boolean pendingAdd)

  Indicates that a validation request is being made for a record that will ultimately be saved with an "add" request, as opposed to an "update" request. This context is necessary for some validators because the nature of the validation depends on whether we are adding or updating a record. The system sets this flag when processing interim validations, such as those fired when DynamicForm.validateOnChange is in force.

  Parameters:

  pendingAdd - New pendingAdd value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getPendingAdd

  public java.lang.Boolean getPendingAdd()

  Indicates that a validation request is being made for a record that will ultimately be saved with an "add" request, as opposed to an "update" request. This context is necessary for some validators because the nature of the validation depends on whether we are adding or updating a record. The system sets this flag when processing interim validations, such as those fired when DynamicForm.validateOnChange is in force.

  Returns:

  Current pendingAdd value. Default value is null

• setProgressiveLoading

  public DSRequest setProgressiveLoading(java.lang.Boolean progressiveLoading)

  Sets progressive loading mode for this particular request, overriding the OperationBinding- and DataSource-level settings. This setting overrides the progressiveLoadingThreshold setting as well, meaning that if DSRequest.progressiveLoading is explicitly set to false Smart GWT won't automatically switch to loading data progressively even if DataSource.progressiveLoadingThreshold is exceeded.

  Note that this setting applies only to fetch requests - it has no effect if specified on any other kind of request.

  Parameters:

  progressiveLoading - New progressiveLoading value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  DataSource.setProgressiveLoading(java.lang.Boolean), DataSource.progressiveLoadingThreshold, OperationBinding.progressiveLoading, Progressive Loading

• getProgressiveLoading

  public java.lang.Boolean getProgressiveLoading()

  Sets progressive loading mode for this particular request, overriding the OperationBinding- and DataSource-level settings. This setting overrides the progressiveLoadingThreshold setting as well, meaning that if DSRequest.progressiveLoading is explicitly set to false Smart GWT won't automatically switch to loading data progressively even if DataSource.progressiveLoadingThreshold is exceeded.

  Note that this setting applies only to fetch requests - it has no effect if specified on any other kind of request.

  Returns:

  Current progressiveLoading value. Default value is null

  See Also:

  DataSource.getProgressiveLoading(), DataSource.progressiveLoadingThreshold, OperationBinding.progressiveLoading, Progressive Loading

• getRequestId

  public java.lang.String getRequestId()

  Automatically generated unique ID for this request. This ID will be required by developers making use of the "clientCustom" dataProtocol.

  Returns:

  Current requestId value. Default value is varies

• getResultSet

  public ResultSet getResultSet()

  For advanced use in integrating dataset paging with web services, the ResultSet that issued this "fetch" DSRequest is automatically made available as the resultSet property.

  This property can only be read. There is no meaning to setting this property yourself.

  Returns:

  Current resultSet value. Default value is null

• getResultTree

  public ResultTree getResultTree()

  For advanced use in integrating trees that load data on demand with web services, the ResultTree that issued this "fetch" DSRequest is automatically made available as the resultTree property.

  This property can only be read. There is no meaning to setting this property yourself.

  Returns:

  Current resultTree value. Default value is null

• setShouldUseCache

  public DSRequest setShouldUseCache(java.lang.Boolean shouldUseCache)

  This is a per-request flag for explicitly controlling whether the cache is used (bypassing it when not wanted, or using it when settings would indicate otherwise). See DataSource.cacheAllData, DataSource.cacheAllOperationId and DataSource.cacheAcrossOperationIds for caching management for all requests of a dataSource.

  Parameters:

  shouldUseCache - New shouldUseCache value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getShouldUseCache

  public java.lang.Boolean getShouldUseCache()

  This is a per-request flag for explicitly controlling whether the cache is used (bypassing it when not wanted, or using it when settings would indicate otherwise). See DataSource.cacheAllData, DataSource.cacheAllOperationId and DataSource.cacheAcrossOperationIds for caching management for all requests of a dataSource.

  Returns:

  Current shouldUseCache value. Default value is null

• setStartRow

  public DSRequest setStartRow(java.lang.Integer startRow)

  Starting row of requested results, used only with fetch operations. If unset, 0 is assumed.

  Note that startRow and endRow are zero-based, inclusive at the beginning and exclusive at the end (like substring), so startRow: 0, endRow: 1 is a request for the first record.

  Parameters:

  startRow - New startRow value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getStartRow

  public java.lang.Integer getStartRow()

  Starting row of requested results, used only with fetch operations. If unset, 0 is assumed.

  Note that startRow and endRow are zero-based, inclusive at the beginning and exclusive at the end (like substring), so startRow: 0, endRow: 1 is a request for the first record.

  Returns:

  Current startRow value. Default value is null

• setStreamResults

  public DSRequest setStreamResults(boolean streamResults)

  If true, results will be streamed on the server, rather than all records being read into server memory at once; this approach is appropriate for retrieving or exporting large datasets without swamping the server.

  Although this property can be set without any particular concerns (small datasets can be streamed just as readily as large ones), bear in mind that although streaming enables the processing of very large datasets, processing and downloading very large datasets in a normal client/server flow will very rarely give an acceptable user experience. Streaming is of more practical use in a batch setting - for example, a disconnected export.

  Note that streaming requires specific server support; of Smart GWT's built-in DataSource types, only SQLDataSource is able to stream results. This property is ignored by other DataSource types. If you wish to implement the necessary server-side behavior to support streaming with a custom DataSource, see the server-side Javadocs for DSResponse.hasNextRecord() and DSResponse.nextRecordAsObject().

  See also the server-side documentation for DSResponse, SQLDataSource and StreamingResponseIterator.

  Note, that streaming results does not support fields with "concat" summary function on non-Oracle databases. Such fields will be skipped.

  Parameters:

  streamResults - New streamResults value. Default value is false

  Returns:

  DSRequest instance, for chaining setter calls

• getStreamResults

  public boolean getStreamResults()

  If true, results will be streamed on the server, rather than all records being read into server memory at once; this approach is appropriate for retrieving or exporting large datasets without swamping the server.

  Although this property can be set without any particular concerns (small datasets can be streamed just as readily as large ones), bear in mind that although streaming enables the processing of very large datasets, processing and downloading very large datasets in a normal client/server flow will very rarely give an acceptable user experience. Streaming is of more practical use in a batch setting - for example, a disconnected export.

  Note that streaming requires specific server support; of Smart GWT's built-in DataSource types, only SQLDataSource is able to stream results. This property is ignored by other DataSource types. If you wish to implement the necessary server-side behavior to support streaming with a custom DataSource, see the server-side Javadocs for DSResponse.hasNextRecord() and DSResponse.nextRecordAsObject().

  See also the server-side documentation for DSResponse, SQLDataSource and StreamingResponseIterator.

  Note, that streaming results does not support fields with "concat" summary function on non-Oracle databases. Such fields will be skipped.

  Returns:

  Current streamResults value. Default value is false

• setTextMatchStyle

  public DSRequest setTextMatchStyle(TextMatchStyle textMatchStyle)

  For "fetch" operations, how search criteria should be interpreted for text fields: one of "exact" for exact match, "exactCase" for case-sensitive exact match, "startsWith" for matching at the beginning only, or "substring" for substring match. All textMatchStyle settings except "exactCase" are case-insensitive; use AdvancedCriteria for greater control over matching.

  This property defaults to the value of DataSource.defaultTextMatchStyle if it is not explicitly provided on the DSRequest. Note, however, that DSRequests issued by ListGrids and other components will generally have a setting for textMatchStyle on the component itself (see ListGrid.autoFetchTextMatchStyle, for example).

  This setting is respected by the built-in server-side connectors for SQL, JPA and Hibernate. A custom server-side DataSource implementation should generally respect this flag as well, or server-side filtering will not match client-side filtering, which will require disabling client-side filtering, a huge performance loss.

  Parameters:

  textMatchStyle - New textMatchStyle value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getTextMatchStyle

  public TextMatchStyle getTextMatchStyle()

  For "fetch" operations, how search criteria should be interpreted for text fields: one of "exact" for exact match, "exactCase" for case-sensitive exact match, "startsWith" for matching at the beginning only, or "substring" for substring match. All textMatchStyle settings except "exactCase" are case-insensitive; use AdvancedCriteria for greater control over matching.

  This property defaults to the value of DataSource.defaultTextMatchStyle if it is not explicitly provided on the DSRequest. Note, however, that DSRequests issued by ListGrids and other components will generally have a setting for textMatchStyle on the component itself (see ListGrid.autoFetchTextMatchStyle, for example).

  This setting is respected by the built-in server-side connectors for SQL, JPA and Hibernate. A custom server-side DataSource implementation should generally respect this flag as well, or server-side filtering will not match client-side filtering, which will require disabling client-side filtering, a huge performance loss.

  Returns:

  Current textMatchStyle value. Default value is null

• setUseFlatFields

  public DSRequest setUseFlatFields(java.lang.Boolean useFlatFields)

  When useFlatFields is set for a request to be sent to a WSDL web service, when creating the input XML message to send to the web service, properties in request.data will be used as the values for XML elements of the same name, at any level of nesting.

  useFlatFields allows you to ignore gratuitous XML message structure, such as extra levels of nested elements, and provides some insulation against changes in the required structure of the input message.

  For example, given this input message:

    <FindServices>
        <searchFor>search text</searchFor>
        <Options>
            <caseSensitive>false</caseSensitive>
        </Options>
        <IncludeInSearch>
            <serviceName>true</serviceName>
            <documentation>true</documentation>
            <keywords>true</keywords>
        </IncludeInSearch>
    </FindServices>
    

  If useFlatFields were not set, in order to fill out this message correctly, request.data would need to be:

  {
       searchFor: "search text",
       Options : {
           caseSensitive: false,
       },
       IncludeInSearch : {
           serviceName: true,
           documentation : true,
           keywords : true
       }
    }

  However if useFlatFields were set, request.data could be just:

  {
       searchFor: "search text",
       caseSensitive: false,
       serviceName: true,
       documentation : true,
       keywords : true
    }

  useFlatFields is often set when the input data comes from a DynamicForm to avoid the cumbersome and fragile process of mapping input fields to an XML structure.

  OperationBinding.useFlatFields can also be set to cause all dsRequests of a particular type to useFlatFields automatically.

  For DataBoundComponents, component.useFlatFields can be set use "flattened" binding to fields of a WSDL message or XML Schema.

  Note that useFlatFields is not generally recommended for use with XML input messages where multiple simple type fields exist with the same name, however if used in this way, the first field to use a given name wins. "first" means the first field encountered in a depth first search. "wins" means only the first field will be populated in the generated XML message.

  Parameters:

  useFlatFields - New useFlatFields value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getUseFlatFields

  public java.lang.Boolean getUseFlatFields()

  When useFlatFields is set for a request to be sent to a WSDL web service, when creating the input XML message to send to the web service, properties in request.data will be used as the values for XML elements of the same name, at any level of nesting.

  useFlatFields allows you to ignore gratuitous XML message structure, such as extra levels of nested elements, and provides some insulation against changes in the required structure of the input message.

  For example, given this input message:

    <FindServices>
        <searchFor>search text</searchFor>
        <Options>
            <caseSensitive>false</caseSensitive>
        </Options>
        <IncludeInSearch>
            <serviceName>true</serviceName>
            <documentation>true</documentation>
            <keywords>true</keywords>
        </IncludeInSearch>
    </FindServices>
    

  If useFlatFields were not set, in order to fill out this message correctly, request.data would need to be:

  {
       searchFor: "search text",
       Options : {
           caseSensitive: false,
       },
       IncludeInSearch : {
           serviceName: true,
           documentation : true,
           keywords : true
       }
    }

  However if useFlatFields were set, request.data could be just:

  {
       searchFor: "search text",
       caseSensitive: false,
       serviceName: true,
       documentation : true,
       keywords : true
    }

  useFlatFields is often set when the input data comes from a DynamicForm to avoid the cumbersome and fragile process of mapping input fields to an XML structure.

  OperationBinding.useFlatFields can also be set to cause all dsRequests of a particular type to useFlatFields automatically.

  For DataBoundComponents, component.useFlatFields can be set use "flattened" binding to fields of a WSDL message or XML Schema.

  Note that useFlatFields is not generally recommended for use with XML input messages where multiple simple type fields exist with the same name, however if used in this way, the first field to use a given name wins. "first" means the first field encountered in a depth first search. "wins" means only the first field will be populated in the generated XML message.

  Returns:

  Current useFlatFields value. Default value is null

• setUseFlatHeaderFields

  public DSRequest setUseFlatHeaderFields(java.lang.Boolean useFlatHeaderFields)

  Cause the useFlatFields XML serialization behavior to be used for all soap headers in the request. See also headerData.

  Parameters:

  useFlatHeaderFields - New useFlatHeaderFields value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

• getUseFlatHeaderFields

  public java.lang.Boolean getUseFlatHeaderFields()

  Cause the useFlatFields XML serialization behavior to be used for all soap headers in the request. See also headerData.

  Returns:

  Current useFlatHeaderFields value. Default value is null

• setUseStrictJSON

  public DSRequest setUseStrictJSON(java.lang.Boolean useStrictJSON)

  Should the HTTP response to this request be formatted using the strict JSON subset of the javascript language? If set to true, responses returned by the server should match the format described here.

  Only applies to requests sent a server with DataSource.dataFormat set to "json" or "iscServer".

  Overrides:

  setUseStrictJSON in class RPCRequest

  Parameters:

  useStrictJSON - New useStrictJSON value. Default value is null

  Returns:

  DSRequest instance, for chaining setter calls

  See Also:

  setUseStrictJSON(java.lang.Boolean)

• getUseStrictJSON

  public java.lang.Boolean getUseStrictJSON()

  Should the HTTP response to this request be formatted using the strict JSON subset of the javascript language? If set to true, responses returned by the server should match the format described here.

  Only applies to requests sent a server with DataSource.dataFormat set to "json" or "iscServer".

  Overrides:

  getUseStrictJSON in class RPCRequest

  Returns:

  Current useStrictJSON value. Default value is null

  See Also:

  getUseStrictJSON()

• setValidationMode

  public DSRequest setValidationMode(ValidationMode validationMode)

  Mode of validation for entered data.

  Parameters:

  validationMode - New validationMode value. Default value is "full"

  Returns:

  DSRequest instance, for chaining setter calls

• getValidationMode

  public ValidationMode getValidationMode()

  Mode of validation for entered data.

  Returns:

  Current validationMode value. Default value is "full"

• setAttribute

  public DSRequest setAttribute(java.lang.String property,
                                java.lang.Object value)

  Set a custom attribute value on the DSRequest as an Object. Note that this method converts the Java primitive Object types, Dates and Maps to the underyling JavaScriptObject value. All other object types are set as Object type attributes and users are expected to call DataClass.getAttributeAsObject(String) in order to retrieve them.

  These attributes are available for client-side use only - these attributes are not transmitted to the server.

  Do not use setAttribute() to set any attribute for which there is a dedicated setter (do not setAttribute("data", data) for example).

  If you are looking for a way to send additional data to the server, read DsRequestEquivalence for the best approach.

  Overrides:

  setAttribute in class DataClass

  Parameters:

  property - the attribute name

  value - the attribute value.

  Returns:

  DSRequest instance, for chaining setter calls

• setParams

  public DSRequest setParams(java.util.Map params)

  Description copied from class: RPCRequest
  Values to be sent as simple HTTP params, as a JavaScript Object where each property/value pair will become an HTTP parameter name and value. These parameters are then accessible on the server, for example, using servletRequest.getParameter(paramName) in Java Servlets.

  Array-valued parameters will be submitted as multiple instances of the same parameter, similar to an HTML form with a multi-select (?paramName=value1&paramName=value2 ...), accessible as getParameterValues(paramName) in Java Servlets. Any non-atomic type, such as an Object, will be serialized to JSON by the JSONEncoder. If this isn't desirable, serialize the data in advance so that the value provided in rpcRequest.params is a String.

  Note that this API is primarily used in combination with useSimpleHttp - when contacting the Smart GWT Server, use data instead, which provides full JavaScript <-> Java translation of arbitrary structures. rpcRequest.params can also be used with the Smart GWT Server, where it provides an an opportunity to send additional data aside from the main data payload. This is useful for adding data to DataSource requests which will be kept separate from the automatically sent DataSource data, or for making parts of the request visible in the URL for HTTP-level logging or layer 4 switches.

  Note that in contrast to data object, the data in rpcRequest.params is not deserialized by the Smart GWT server, and all values arrive on the server as String type (like HTTP parameters always do).

  Note: The params are submitted once per http transaction. If you are using request queuing to bundle multiple RPCRequests or DSRequests into a single HTTP turnaround, the params from the various RPCRequests will be merged, with the later-queued transactions winning on parameter name collisions. A warning will be logged in the Developer Console if multiple RPCRequests specified params.

  Overrides:

  setParams in class RPCRequest

  Parameters:

  params - New params value. Default value is null

  Returns:

  RPCRequest instance, for chaining setter calls

• setCallback

  public final void setCallback(DSCallback callback)

• setSortBy

  public void setSortBy(SortSpecifier[] sortSpecifiers)

  Fieldnames to sortBy.

  Parameters:

  sortSpecifiers - Default value is null

• setSortBy

  public void setSortBy(SortSpecifier sortSpecifier)

  Fieldnames to sortBy.

  Parameters:

  sortSpecifier - Default value is null

• getSortBy

  public SortSpecifier[] getSortBy()

  Fieldname to sortBy

  Returns:

  SortSpecifier array

• setSummaryFunctions

  public void setSummaryFunctions(java.util.Map<java.lang.String,SummaryFunctionType> summaryFunctions)

  A mapping from field names to summary functions to be applied to each field.

  Valid only for an operation of type "fetch". See the Server Summaries overview in the client-side documentation for details and examples of usage.

  NOTE: this feature is supported only in Power Edition or above, and only when using the built-in SQL, JPA or Hibernate connectors.

  Parameters:

  summaryFunctions - Map<String,SummaryFunction> with field names as keys and summary functions as values.

  See Also:

  DSRequest.setGroupBy(String[])

• getSummaryFunctions

  public java.util.Map<java.lang.String,SummaryFunctionType> getSummaryFunctions()

  A mapping from field names to summary functions to be applied to each field.

  Valid only for an operation of type "fetch". See the Server Summaries overview in the client-side documentation for details and examples of usage.

  NOTE: this feature is supported only in Power Edition or above, and only when using the built-in SQL, JPA or Hibernate connectors.

  Returns:

  Map<String,SummaryFunction> with field names as keys and summary functions as values.

  See Also:

  DSRequest.getGroupBy()

• setRawSummaryFunctions

  public void setRawSummaryFunctions(java.util.Map<java.lang.String,java.lang.String> summaryFunctions)

  Same as #setSummaryFunctions(), but allowing to set any functions, not just ones built into the framework, so that in combination with custom implementation on the server-side you can perform custom aggregation. See the Server Summaries > Custom Aggregation example in the Showcase.

  NOTE: this feature is supported only in Power Edition or above, and only when using the built-in SQL, JPA or Hibernate connectors.

  Parameters:

  rawSummaryFunctions - Map<String,String> with field names as keys and summary functions as values.

  See Also:

  DSRequest.setGroupBy(), DSRequest.setSummaryFunctions()

• getRawSummaryFunctions

  public java.util.Map<java.lang.String,java.lang.String> getRawSummaryFunctions()

  Same as getSummaryFunctions(), but allowing to get any functions, not just ones built into the framework, so that in combination with custom implementation on the server-side you can perform custom aggregation. See the Server Summaries > Custom Aggregation example in the Showcase.

  NOTE: this feature is supported only in Power Edition or above, and only when using the built-in SQL, JPA or Hibernate connectors.

  Returns:

  Map<String,String> with field names as keys and summary functions as values.

  See Also:

  DSRequest.setGroupBy(), DSRequest.setSummaryFunctions()

• setOldValues

  public void setOldValues(java.util.Map oldValues)

  For an update or remove operation, the original values from the record that is being updated or removed. oldValues is automatically added to DSRequests submitted by DataBound Components. Available on the server via DSRequest.getOldValues().

  The server can compare the oldValues to the most recent stored values in order to detect that the user was looking at stale values when the user submitted changes (NOTE: this means of detecting concurrent edit is sometimes called "optimistic concurrency" or "long transactions").

  In applications where a policy of "last update wins" is not appropriate when updating certain fields, special UI can be shown for this case. For example, on detecting concurrent edit, the server may send back a special dsResponse.status code that the client application detects, offering the user a choice of proceeding with the operation, discarding edits, or reconciling new and old values in a special interface.

  Parameters:

  oldValues - oldValues Default value is null

• setOldValues

  public void setOldValues(com.google.gwt.core.client.JavaScriptObject oldValues)

  For an update or remove operation, the original values from the record that is being updated or removed. oldValues is automatically added to DSRequests submitted by DataBound Components. Available on the server via DSRequest.getOldValues().

  The server can compare the oldValues to the most recent stored values in order to detect that the user was looking at stale values when the user submitted changes (NOTE: this means of detecting concurrent edit is sometimes called "optimistic concurrency" or "long transactions").

  In applications where a policy of "last update wins" is not appropriate when updating certain fields, special UI can be shown for this case. For example, on detecting concurrent edit, the server may send back a special dsResponse.status code that the client application detects, offering the user a choice of proceeding with the operation, discarding edits, or reconciling new and old values in a special interface.

  Parameters:

  oldValues - oldValues Default value is null

• getCriteria

  public Criteria getCriteria()
                       throws java.lang.IllegalStateException

  Return the Criteria associated with a FETCH operation.

  Note : This method should only be called during a FETCH operation

  Returns:

  the criteria

  Throws:

  java.lang.IllegalStateException - if called for a non-fetch operation

• setSkinName

  public void setSkinName(java.lang.String skinName)

  Set the skin to use. For example: Enterprise

  Parameters:

  skinName - the name of the selected skin.

• setCriteria

  public DSRequest setCriteria(Criteria criteria)

  This method applies to "fetch" requests only; for update or delete operations pass a Record to setData() which contains primaryKey values as Record attributes.

  If you need to do a remove with criteria rather than a primary key, the recommended approach is to do it via a custom operation. so the intent is clear. You can also do it as a remove, but just use DSRequest.oldValues as the source for whatever criteria values you need. That covers everything except AdvancedCriteria.

  Parameters:

  criteria - the criteria to store.