Does anyone has experience formatting data returned from Json /Sql with specific formatters?
I see that the data formatters are limited in types/regexp and I would like to extend this with specific classes (for instance a timestamp to geolocalized date converter)
I’m thinking of a AbstractDataFomatter class with a single String format(Object value) that would be inherited by specific formatters, which would be declared with a “class:” prefix in the xml format part.
YARG provides an ability to format data in a custom way:
Look at the DefaultFormatProvider interface. It has one method String format(Object o). It is called when format for the parameter is not defined in the report. By adding a custom implementation of the interface, you can apply any logic to the field.
Let me bring an example of how the DefaultFormatProvider may be customized in a CUBA-project:
CUBA reporting has an implementation of the interface: CubaFieldFormatProvider.
In the reports-spring.xml the desired DefaultFormatProvider is set as a parameter of CubaFormatterFactory (which extends DefaultFormatterFactory from YARG).
So when the report is launched from UI the CubaFieldFormatProvider is used.
If we want to customize the DefaultFormatProvider we should create an implementation of the interface in our project.
public class CustomFormatProvider implements DefaultFormatProvider{
@Override
public String format(Object o) {
if (o != null) {
if (o instanceof Date) {
SimpleDateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy");
return dateFormat.format(o);
}
.......
}
}
And setup spring.xml of the project. CubaFieldFormatProvider should use our class.
As result, all the dates in reports by default will have the “dd/MM/yyyy” format.
At the moment the DeaultFormatProvider works as described only with DOC/DOCX reports.
In XLS/XLSX it is applied to values only if they are not Boolean/Number/Date (is applied to String). As the format of cells from the template is applied to such fields.
It applies converters on each individual result if needed. The converters themselves are a bunch of java classes, consuming raw data and producing strings.
This way I can produce the required parameter format for all report output format, with a Band/Query/parameter granularity.