Basically I am looking for a way to do bi-directional transformation from an Object root (i.e. bean) to and from a mainframe/cobol fixed-length file.
Initially I thought that I will have to write it all myself. When I discovered BeanWrapperFieldSetMapper I was really excited. It looks like the "read from file into an object" part is done. I really like that it provides a nice way to register custom property editors to do transparent type conversion around common Cobol data types (that is, for example, if I need to convert 0000012345 into 12.345 BigDecimal, I can do it). THANK YOU, Dave, thank you, guys.
Well, then I started looking for a way to persist my bean (or more precisely any object can be handled with BeanWrapperImpl) back into such a file, and I didn't find anything clearly satisfactory.
It seems that FlatFileItemWriter can be used with a yet-to-be-written Transformer, say, BeanWrapperTransformer to achieve it.
I think such capability is an important feature and would add real value to the framework.
1. Basically I think we need a better abstraction of a flat-file structure.
The problem with FixedLengthLineAggregator is that padding and alignment is often type specific. That is Numeric types are typically right-justified and padded with leading zeros, while textual types are left-justified with trailing spaces. So, this info needs to be specified on a per Range basis. I propose we add optional 'padding' and 'alignment' attribute to a Range class, and make it implement Comparable (where comparison is delegated to the min attribute, i.e. starting position), so we can sort them if we need to.
2. We need support for literal values, that is to tell declaratively 'Fill the Range 4:7 with 'XXX' value.
Presumably, we can reuse the same idea that the DefaultFieldSet uses, that is represent a record structure with an array of property names and an array of Ranges, then BeanWrapperTransformer can detect that if the property name starts with 'literal:', it should just use this value and not query the actual bean (that is passed as an argument to a transform method).
3. Implement the BeanWrapperTransformer (it will extend DefaultPropertyEditorRegistrar)
4. (Optional) Create proper PropertyEditors to convert to and from typical mainframe data types like BigDecimal (000012345 -> 12.345 where scale is configurable) and Boolean ('Y' and 'N' - the values should be configurable). The actual padding will be done inside the Transformer based on the individual Range configurations, but the type conversion will delegate to property editors.
I will be more than happy to write it (I am almost done actually). If you guys approve it of the idea, then I will submit a patch. I hope there is still time for it to make it into 1.0 release.
Let me know if you want to take the discussion off-line or into JIRA.
Thanks a lot for your consideration.