Hi, James and Tim,
This looks like great stuff!
Let's not forget localization, though. For international sites, the
formatDate & formatNumber tags need another attribute:
locale="<% someLocale %>"
DateFormat and NumberFormat both provide a constructor that takes a Locale
as a parameter.
Cheers,
Jonathan
-----Original Message-----
From: James Strachan [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 27, 2001 6:37 AM
To: [EMAIL PROTECTED]
Subject: Re: datetime TAGlib -> FormatTag.java
Hi Tim
Thanks for your reply Tim - I've actually checked with the JavaDoc so have a
clearer idea of what I was talking about :-)
> > <i18n:formatDate value="<%= new Date() %>" style="short"/>
> >
> > <i18n:formatDate value="<%= new Date() %>" pattern="yyyy.MMMMM.dd GGG
> > hh:mm"/>
>
> style and pattern are both used identically in MessageFormat
I wasn't really thinking of using MessageFormat in the implementation of
these tags - I was thinking of using the DateFormat / SimpleDateFormat or
NumberFormat / DecimalFormat classes directly.
For Dates I'd prefer to keep both style and pattern attributes. Then the
implementation code can branch efficiently dending on which attribute is
used. If style is specified it could use DateFormat, if a pattern is
specified it could use SimpleDateFormat.
> if we're going with a formatDate, might as well have a formatTime
attribute
> too.
I just checked the JDK and for DateFormat we have 2 options
date = DateFormat.getDateInstance( style, locale );
time = DateFormat.getTimeInstance( style, locale );
which would map to the following quite nicely
<i18n:formatDate value="<%= date %>" style="short"/>
<i18n:formatTime value="<%= date %>" style="full"/>
However there's also this option:-
datetime = DateFormat.getDateTimeInstance( dateStyle, timeStyle, locale );
so we may also want to add for completeness the tag
<i18n:formatDateTime value="<%= date %>" dateStyle="short"
timeStyle="short"//>
I'd probably make formatDate the only one that took an optional pattern
attribute. There doesn't seem any point allowing <formatTime> or
<formatDateTime> to take a pattern, as they would be behaving identically as
<formatDate>
> > <i18n:formatNumber value="<%= 12345.1234 %>"
> > pattern="##,###,###.##"/>
> >
> > <i18n:formatCurrency value="<%= 12345.1234 %>"
> > pattern="##,###,###.##"/>
>
> formatCurrency doesn't actually work to have a pattern. currencies are
> formatted according to locale-specific rules, so patterns don't make
sense.
Well spotted. I hadn't read the java.text JavaDocs for a while and had got
things a little mixed up.
If we ignore patterns for a moment, we have the following choices...
format = NumberFormat.getInstance( locale );
format = NumberFormat.getCurrencyInstance( locale );
format = NumberFormat.getPercentInstance( locale );
Incidentally I'm not sure the difference between these two are:-
NumberFormat.getInstance( locale );
NumberFormat.getNumberInstance( locale );
So we might want to have the following tags implement the currency and
percent features which wouldn't need a style or pattern attribute:-
<i18n:formatCurrency value="<%= 1234.56 %>"/>
<i18n:formatPercent value="<%= 1234.56 %>"/>
For number then a pattern attribute would be optional.
<i18n:formatNumber value="<%= 1234.56 %>"/>
<i18n:formatNumber value="<%= 1234.56 %>" pattern="##,###.##"/>
For completeness you could say that we should consider supporting the
following attributes also to allow the NumberFormat to be configured:-
maxIntegerDigits
minIntegerDigits
maxFractionDigits
minFractionDigits
Though this would mean we'd have to clone the NumberFormat object which
seems a bit unnecessary if we have the pattern mechanism so for now I'd
prefer to leave them out.
> So as I see it the custom format tags would look like this:
So my new proposal would look like this
<i18n:formatDate value="<%= new Date() %>" style="short"/>
<i18n:formatDate value="<%= new Date() %>" pattern="yyyy.MMMMM.dd GGG
hh:mm"/>
<i18n:formatTime value="<%= new Date() %>" style="short"/>
<i18n:formatDateTime value="<%= date %>" dateStyle="short"
timeStyle="short"//>
<i18n:formatNumber value="<%= 1234.56 %>"/>
<i18n:formatNumber value="<%= 1234.56 %>" pattern="##,###.##"/>
<i18n:formatCurrency value="<%= 1234.56 %>"/>
<i18n:formatPercent value="<%= 1234.56 %>"/>
With all the above tags an explicit Locale could be specified or it could be
taken from the current request (or possibly from an outer JSP tag which
defines the default Locale to use).
> one other attribute that might be optional is the value attribute for
date.
Good idea. I think date and time should both be optional and default to
'now'. So
the date is: <i18n:formatDate/>
the time is: <i18n:formatTime/>
the datetime is: <i18n:formatDateTime/>
would print the current date and time - using the default formatting for a
locale.
> back to currency for a seciond -- when dealing with locales, currency gets
> messy because although I may be displaying a page in japanese, if I have a
> number whose value is in US Dollars, I'd better not use the japanese
> locale's formatCurrency! perhaps currency SHOULD be a different tag, but
not
> allow a pattern to be provided, but instead a locale? hmm...
Agreed - its a tricky problem.
I think when displaying (say) US Dollars then I think you need to explicitly
use the US Dollar Locale when printing the number out - rather than relying
on the users or JVM's Locale.
<i18n:formatCurrency value="<%= dollarValue %>" locale="<%= Locale.US %>"/>
We may want some currency converter tag library one day, using some
conversion mechanism.
<i18n:convertCurrency value="<%= dollarValue %>" fromLocale="<%= Locale.US
%>" toLocale="<%= Locale.TAIWAN %>"/>
But I'll leave that out of scope for now ;-)
> one other thing to consider is whether this should be part if i18n. it
> wouldn't strictly have to be, because you're not really using the bundle
> that the i18n taglib chooses. it could be a completely separate taglib
that
> just uses whatever locale is listed by the request object as the preferred
> locale.
>
> however, I think it is a really good idea to make it part of i18n, because
> if you are using i18n, you'd want these format tags to use the same locale
> -- i18n doesn't necessarily use the preferred locale if a bundle isn't
> available for it.
Agreed.
I like the idea of all i18n formatting of messages, dates, numbers etc being
together, so adding these new tags to i18n seems a good idea to me. Plus now
we've a fairly clear design now, they'd be quite lightweight to implement.
Thoughts?
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
