I like it except I don't see why we need multiple editions of
FormatRecord (a low level binary structure mapping to an Excel BIFF
record).
I think I prefer the following signature:
int HSSFDataFormat.getFormat(String format, String locale);
Within that we could have a hashmap of locales that held maps of format
strings to ints.
Orrrr.....
int HSSFDataFormat.getFormat(String format, HSSFLocale locale);
HSSFLocale could hold the actual functionality. Anything else that got
localized could take an instance (subclass) of HSSFLocale. The locale
would conform to the following interface for the moment:
...
getFormat(String format);
...
As we localize more things the methods would be added as abstract
functions to the parent HSSFLocale. This way they'd have to be
implemented for every locale as needed.
Thoughts? Localization/Globalization is really important to our
userbase. Everyone should get interested in this. BTW it looks great
on the resume too :-)
-Andy
On Fri, 2002-03-15 at 11:22, Lo�c Lef�vre wrote:
> How about centralize the different formats used in Excel.
>
> I explain:
> As I've seen, there are two places where we can find the
> data (date, number...) formats: HSSFDataFormat and Workbook.
>
> The ones in the class Workbook are the new ones (personal formats)
> added to the general ones which stand in HSSFDataFormat.
>
> As I understood, when one want to specify a format to a cell, let's
> say a date format, one has to specify the code of this format or
> the pattern (for example: mmmm-yy ). If the pattern mode is used,
> then the format has to be declared in the HSSFDataFormat. If the
> specified pattern is not present, then a -1 code format is returned.
>
> Well how about localize all these formats (default ones) thus, one can
> do this:
>
> HSSFCellStyle cs = wb.createCellStyle();
> cs.setDataFormat( HSSFDataFormat.getFormat("(# ##0 F_);[Rouge](# ##0
> F)") );
>
> which is the french equivalent for the english/us pattern:
> ($#,##0_);[Red]($#,##0)
>
> And they it seems, they have the same code!
>
> So according to the Locale.getDefault() locale object,
> the HSSFDataFormat.getFormat( /* localized pattern */ ) would return the
> good code.
> Thus, an other idea comes: how about to declare constants for the different
> patterns?
> eg:
> public static short GENERAL = 0; // 0, "General"
> public static short NUMBER_DEFAULT = 1; // 1, "0"
> ...
> public static short DATE_DEFAULT = 0xe; // 0xe, US => "m/d/yy", FR =>
> "d/m/yy"
> ...
>
> Seems, the constant names will be somewhat hard to find ;)
>
> After that, in the class Workbook, the method:
>
> protected Record createFormat(int id)
> { // we'll need multiple editions for
> FormatRecord retval = new FormatRecord(); // the differnt formats
>
> switch (id)
> {
>
> case 0 :
> retval.setIndexCode(( short ) 5);
> retval.setFormatStringLength(( byte ) 0x17);
> retval.setFormatString("\"$\"#,##0_);\\(\"$\"#,##0\\)");
> break;
>
> ...
>
> case 7 :
> retval.setIndexCode(( short ) 0x2b);
> retval.setFormatStringLength(( byte ) 0x31);
> retval.setFormatString(
> "_(* #,##0.00_);_(* \\(#,##0.00\\);_(* \"-\"??_);_(@_)");
> break;
> }
> return retval;
> }
>
> will look like:
>
> protected Record createFormat(int id)
> {
> return FormatRecordFactory.getInstance(( short ) id);
> }
>
> See FormatRecordFactory (attachment)
>
> Waiting for your answer(s) :)
>
> Lo�c
--
http://www.superlinksoftware.com
http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound
Document
format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh
