I have a JSF 1.2 view which is kind of a report generator.
Users can select a query, configure some values, then the database is requested and data collected.
After that the data can be viewed in a dataTable and finally is exported to Excel.
Works fine so far.
Depending on the query the columns have different types, one of which is Double.
The Double values should be rounded now...
Since there are many rows (tens or hundreds of thousands) I collect all data as String to avoid time consuming type conversions.
That's pretty ok because for the export to Excel I need Strings, too (written to Office XML).
But now the rounding comes in. In the dataTable the doubles shall be rounded.
If I had a Double I could easily use f:convertNumber, but I don't have.
My idea would be a String converter which analyzes if it is a numeric value
and then formats the String. (Performace is not so critical because there are
only 30 or so records in the paged dataTable). How would I accomplish this?
I think that whatever minor performance benefits you got by not using binary numeric objects it going to be more than negated here.
The easiest way for a converter to add decimal places is to scan the object using a Regular Expression parser and if it's all digits ("^\\d+$" or "^\\d+\\.\\d+$"), convert it to a number and use the formatnumber function.
If you want to avoid converting the number, you can do the Regular Expression scan and follow it up with hammering on the original string object until you've produced one with the requisite number of decimals.
However, either of these methods is more work - and more resources - than simply working with binary objects to begin with.
An IDE is no substitute for an Intelligent Developer.
... that's why I asked. I'm not really sure which way to go.
I'm considering using the right types when collecting the data as well. Do it right in the first place.
For now I'll give the converter a try (need a solution next days) and for the next release
I will go for a cleaner solution with typed data. (This has some implications for the export as well.)
That works too. Exceptions resource users, although without running real-world benchmarks I can't say which one costs more - Regular Expression parsing or your approach. As they say, Your Mileage May Vary.