| Category: | Feature request |
Priority: | Normal |
Status: | New |
| Project: | Severity: | Minor |
Resolution: | Open |
|
| Component: | Reproducibility: | Always |
Assigned to: |
Well, generally.
A data source type can be used as a source for a query input control if the following assumptions are correct. The problems related to each assumption are outlined below:
* there is a QueryExecuter for the data source type
Some JRDataSources do not have QueryExecuters, like a CSV data source, so they cannot be used. The solution would be to have a default query executer for these types of data sources that don't have QueryExecuters.
* the QueryExecuter only uses the field name to get the value from the queried result
Some QueryExecuters use the field description, like an XML Data Source. When defining fields for the query, an optional description should be able to be entered.
* The getFieldValue returns an object of the right class for display
Some QueryExecuters use the indicated class of the defined field to transform the value from the query result into the desired object, like an XML data source. When defining fields for the query, an optional field class should be able to be entered.
* Data cannot be filtered or sorted apart from in the query itself
Some data sources cannot be sorted or filtered until after the query result returns, which is the reason for the sortField and filterExpression in JRXML. For a good user experience, these options should be made available in the query input control definition, and applied dynamically.
