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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

kiwiwings
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Javen O'Neal
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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

Nick Burch-8
In reply to this post by kiwiwings
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: [hidden email]
For additional commands, e-mail: [hidden email]