DataFormatter vs. org.apache.poi.ss.format classes

[Andreas Beeker <ki...@apache.org>]

Hi,

about 5-6 days ago, I just wanted to fix a few unnecessary cast, but now I'm in the middle
of cell formatting hell :)

Would it be ok, if DataFormatter delegates much of its logic to the org.apache.poi.ss.format
classes?

Currently, I'm struggling with CellNumberFormatter and noticed that the test in TestDataFormatter.testFractions
assume, that a lot of formatting details are skipped, whereas CellNumberFormatter try to
provide most corner cases.
Is there a reason for the simplified handling in DataFormatter or is it just legacy?

Andi


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

Re: DataFormatter vs. org.apache.poi.ss.format classes

[Javen O'Neal <ja...@gmail.com>]

I'm all for reducing the number of lines of code. If you could consolidate
the two classes or have one class delegate to another, that's a step in the
right direction
On Nov 26, 2015 4:53 PM, "Andreas Beeker" <ki...@apache.org> wrote:

> Hi,
>
> about 5-6 days ago, I just wanted to fix a few unnecessary cast, but now
> I'm in the middle
> of cell formatting hell :)
>
> Would it be ok, if DataFormatter delegates much of its logic to the
> org.apache.poi.ss.format
> classes?
>
> Currently, I'm struggling with CellNumberFormatter and noticed that the
> test in TestDataFormatter.testFractions
> assume, that a lot of formatting details are skipped, whereas
> CellNumberFormatter try to
> provide most corner cases.
> Is there a reason for the simplified handling in DataFormatter or is it
> just legacy?
>
> Andi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>

Re: DataFormatter vs. org.apache.poi.ss.format classes

[Nick Burch <ni...@apache.org>]

On 27/11/15 00:53, Andreas Beeker wrote:
> Would it be ok, if DataFormatter delegates much of its logic to the org.apache.poi.ss.format
> classes?

I actually ended up doing that for one case a month or so back! You 
should notice a TODO at the top of both DataFormatter and CellFormat 
saying they need to be merged...

> Currently, I'm struggling with CellNumberFormatter and noticed that the test in TestDataFormatter.testFractions
> assume, that a lot of formatting details are skipped, whereas CellNumberFormatter try to
> provide most corner cases.
> Is there a reason for the simplified handling in DataFormatter or is it just legacy?

I believe that in the beginning, DataFormatter tried to give you an 
Excel-like string in most cases, while CellFormat aimed to give you 
information on what colour was used if the format had colours etc, but 
CellFormat had a much smaller range of formats handled. CellFormat has 
some support for padding cells, DataFormatter deliberately trims / 
doesn't pad. IIRC, both were (mostly?) community contributions. Both 
have expanded their coverage from community and committer patches over 
the years!

DataFormatter works for HSSF and XSSF eventmodel cases too, while I 
think CellFormat is usermodel only. I seem to recall that one of them 
has a CSV mode too, can't quite remember what that does differently though!

I think we have a pretty good set of unit tests for both these days, so 
if you did want to do more consolidation of logic, we can hopefully pick 
up any breakages quite quickly!

Oh, and if you're in there, then bear in mind that the CellFormat stuff 
could potentially be the basis for Conditional Formatting evaluation in 
future. There's quite a lot of functionality overlap in Excel itself 
between custom format strings with colours and conditional formatting, 
so hopefully we can share code on our side too. Please don't break the 
ability to add that later if possible!

Thanks
Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org