3) use explicit format names: numberFormat, timeFormat, dateFormat and
timestampFormat, instead of a generic 'format' parameter defaulting to
an ubiquitous 'default' value. I'd also like to have the default formats
be the international formats used by HTML5 (RFC 3339).
+1000
:-)
The new formatting styles implementation is on its way. I'm not sure
I'll change the default, though, because it would imply changing the
tool itself (like deprecating DateTool in favor of an almost identical
CalendarTool) for backward compatibility.
4) On the same subject of formats, I'd also would like to introduce
date/time format sniffing (as there are some good algorithms out there
that we can borrow). We could maybe do the sniffing once and cache the
detected format in the AST (but it should be configurable, and probably
default to false).
What is the use-case here? Velocity should primarily be used for
output-generation, so the tools we provide should be for e.g.
java.util.Date -> java.lang.String, not the other way around.
I must admit, I've found myself using some Velocity-Tools classes as
hacks (e.g. re-formatting a date that is in a dumb format for some
reason), but it would be better not to encourage that kind of foolishness.
Well, we made some steps towards automatic conversions between main
standard types, so it just seems to me that being able to parse a date
without having to specify its format as long as it can be recognized is
a feature that adds some completeness and comfort in the same direction.
For instance, let say you want to call a method which takes a Date as
argument, and that you have a parameter which, for some reason, could be
either a simple date or a full datetime. Or, you have an API call
returning a datetime which *sometimes* lacks one field or another, like
milliseconds or time zone. Or you're trying to publish data that comes
from localized files or tables containing different formats. etc.
I'm not sure it does *encourage* any form of bad practice or hacking,
though. I see it as a configurable fallback to which
DateTool.toString(String) can resort whenever using the configured
format fails, and that precisely preserves from writing hackish VTL.
But I may not have the time to deal with it, anyway. And of course I
won't push it if there is a strong opinion against it.
5) I'm pretty inclined to deprecate AlternatorTool, since all designers
now use CSS for this purpose. Plus, we now have #if($foreach.index % 2)
for this purpose.
Deprecating but not removing AlternatorTool is okay for the time being.
Some of us have to support ancient browsers like MSIE8 which don't
support CSS nth-child.
You'll still have #if($foreach.index%2)..., or #set($even =
!$even)#if($even)...
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
