Skip to main content

JXDatePicker default formats should be locale-aware

3 replies [Last post]
Anonymous

Hi there,

just started using the JXDatePicker component and noticed some
inconvenience in how it is ignoring default locale when falling back on
default parsing formats.

Obtaining locale-aware default formatters is easily supported by:
http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html#getDateInstance(int)

The relevant portion of the code in the datepicker for this is here:
https://jdnc.dev.java.net/source/browse/jdnc/swingx/src/java/org/jdeskto...

63 String format = UIManager.getString("JXDatePicker.longFormat");
64 if (format == null) {
65 format = "EEE MM/dd/yyyy";
66 }
67 _formats[0] = new SimpleDateFormat(format);
68
69 format = UIManager.getString("JXDatePicker.mediumFormat");
70 if (format == null) {
71 format = "MM/dd/yyyy";
72 }
73 _formats[1] = new SimpleDateFormat(format);
74
75 format = UIManager.getString("JXDatePicker.shortFormat");
76 if (format == null) {
77 format = "MM/dd";
78 }
79 _formats[2] = new SimpleDateFormat(format);

Two main remarks on this is

[1] why should the configuration not just request the Formatter object
directly from the UIManager, instead of a string format-pattern. Point
being there are quite some people that prefer their own (or apache
provided) parser/formatters above the SimpleDateFormat implementation.

[2] when deciding to fall-back on some defaults, we should be
considering the default locale, and not (as is now) take the US-centric
vision of the world :-)

Suggested new code would thus look like

(1) opt for an abstract member declaration

58 private DateFormat _formats[] = null;

(2) request formats directly + default to locale dependent formats

63 DateFormat format = (DateFormat)UIManager
.get("JXDatePicker.longFormat");
64 if (format == null) {
65 format = DateFormat.getDateInstance(DateFormat.LONG);
66 }
67 _formats[0] = format;
68
69 format = (DateFormat)UIManager
.get("JXDatePicker.mediumFormat");
70 if (format == null) {
71 format = DateFormat.getDateInstance(DateFormat.MEDIUM);
72 }
73 _formats[1] = format;
74
75 format = (DateFormat)UIManager
.get("JXDatePicker.shortFormat");
76 if (format == null) {
77 format = DateFormat.getDateInstance(DateFormat.SHORT);
78 }
79 _formats[2] = format;

Of course, if people would need backwards compatibility (or at least
usefull warnings other then class-cast-exceptions then this should be
augmented with some more intelligent inspection of the types returned by
the UIManager, or by introducing new lookup keys for the formats (as
opposed to the format-patterns) and provide some double fall-back strategy:

1. lookup the format (new key)
2. if it is not there: lookup the string-pattern (todays key)
3. if that is also not there: use the appropriate
DateFormat.getDateInstance(..)

if this makes sense, we could (incorporating discussed options) provide
a patch in the issue-tracking system.

regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
dmouse
Offline
Joined: 2003-06-09

Marc,

Thanks for the comments! The JXDatePicker was quickly written since JDNC needed one. It is definately not as developed as the JXMonthView component yet. These are great suggestions and make a lot of sense.

For tracking purposes would you please enter these issues in the Issue Tracker and either post the IDs or assign them to me (dmouse)? This will help me keep tabs on what we need to do to make this component complete.

Thanks for your help!

Josh

Marc Portier

Josh,

I added two issue for this and the other:
https://jdnc.dev.java.net/issues/show_bug.cgi?id=132
https://jdnc.dev.java.net/issues/show_bug.cgi?id=133

if you (or others) could express their preference towards the backwards
compatibility of the current config keys (issue 132) we could actually
prepare the patch and attach it to the issue

(I already have a cvs checkout locally, I assume you'ld want the patches
in unified format?)

regards,
-marc=

jdnc-interest@javadesktop.org wrote:
> Marc,
>
> Thanks for the comments! The JXDatePicker was quickly written since JDNC needed one. It is definately not as developed as the JXMonthView component yet. These are great suggestions and make a lot of sense.
>
> For tracking purposes would you please enter these issues in the Issue Tracker and either post the IDs or assign them to me (dmouse)? This will help me keep tabs on what we need to do to make this component complete.
>
> Thanks for your help!
>
> Josh
> ---
> [Message sent by forum member 'dmouse' (Joshua Outwater)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=43244&#43244
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>

--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

dmouse
Offline
Joined: 2003-06-09

Marc,

Thanks for submitting the issues. I'm not too concerned about backwards compatibility of the JXDatePicker. It is still in its infancy so I'd rather the design be clean and we remove unnecessary methods/keys.

As you stated in the bug, I'd rather have the component use a date formatter. I'm not sure if it's necessary that we put this in the UIManager. I think accessor methods for this would be better. Maybe we could have a key for the fallback value though if people found that useful.

Regarding the patches, I don't know what format the project generally uses, but unified patches should be fine.

P.S. Feel free to e-mail me as well since I don't check the forums as much as I should :)

Thanks!