Hi again Frank, Am Donnerstag, den 09.02.2006, 15:11 +0100 schrieb Frank Schönheit - Sun Microsystems Germany: > > Do you see any sense in making a helper service concentrating on > this > > kind of tasks? > > Hmm. If it's only about converting a numeric into a string - I don't > think so. Besides the LocaleData thingie, you could, for instance, > also > use the NumberFormatter: create a NumberFormatter instance, attach the > NumberFormatsSupplier obtained from a data source, and use > convertStringToNumber [1]. There also is a property something (not > sure > if at the formatter or the supplier) specifying a locale, IIRC.
No, in fact it is the other way round: I need to convert displayed number strings to real (database ready) numbers for creating SQL statement strings. The number formatter is only one way in converting un-localized strings into localized ones. I really think there should be a service for de-localizing values. A perfect place for this would be an optional method or a set thereof at the number formatters of the DataSource (and maybe the Connection). For scripting that would be a good thing. Now the only way is to parse strings in selfmade code or add a special number format for the underlying database. Maybe each type of database needs multiple format strings for different types (depending on the driver handling conversions like rounding for the correct number of decimal places or not). Something else deeply needed (at least by me, as always ;) would be a database compatible way of asking a SpreadsheetCell for it's value contents. Having such a thing would make a lot of conversions unnecessary (dunno if this is for the dba or sc project). Concluding one could say the way from the document or GUI back to the database should get into the view of responsible API designers. ;) Regards, Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
