Re: [tools] Tools reeng

2016-11-21 Thread Christopher Schultz 
Claude,

On 11/17/16 12:58 PM, Claude Brisson wrote:
> There are several things I'd like to do for the tools before releasing
> them:
> 
> 1) deprecate the ConversionTool:
> - date formatting and parsing methods are redundant with (and less
> complete than) DateTool ones.
> - number formatting and parsing methods are redundant with the
> NumberTool and MathTool ones, and also far less necessary now that a lot
> of automatic conversions are taken care of.
> - the only remaining feature is a toStrings() method (which does
> splitting and optional trimming). A single method does not legitimate
> the need for a tool, and in a web context, the ParameterTool already
> does it for GET/POST parameters. Still, we can have the method move
> elsewhere (but where? Maybe deprecate SortTool and have a CollectionTool
> do splitting and sorting?).
> 
> 2) deprecate MathTool number parsing and formatting methods, which are
> redundant with the NumberTool ones.

Okay to all of the above.

> 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

> 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.

> 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.

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r1770547 - in /velocity/tools/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools: ConversionUtils.java generic/DateTool.java

2016-11-21 Thread Claude Brisson 

Thanks again for your review.

On 21/11/2016 07:22, Sergiu Dumitriu wrote:

Although RFC 3339 says that "Applications [...] may choose, for the sake
of readability, to specify a full-date and full-time separated by (say)
a space character", the standard is to use T as a separator.

And if I'm already nagging, ISO and RFC are two different things, as are
ISO-8601 and RFC 3339, so don't use ISO in the name and RFC in the
comments as if they're interchangeable, pick one and stick with it.

While the RFC allows space as the separator, ISO-8601 actually requires
T as the date-time separator.


I agree I made a compromise, here: we're definitely targeting RFC 3339 
(with the space separator, as we're mostly doing display), but 
nicknaming a format 'rfc' wasn't very illustrative for the end user. 
After all, RFC 3339 is a "profile of the ISO-8601 standard" for Internet.


But anyway, I'm not yet happy with the current 'intl' and 'iso' 
formatting styles so far, so we can review my choices.


Let's summarize. The goal here is to extend the standard Java formatting 
styles ('full', 'long', 'medium', 'short' and 'default' which equals 
'medium') with standardized YMD formats. The current implementation 
proposes 'iso' (for "-MM-dd HH:mm:ssX", but as Sergiu noticed, it's 
not the ISO format but rather an RFC 3339 one), and 'intl' (but 
precisely, not having the time zone part for a format name 'intl' looks 
rather ankward).


Here is another proposal:

 - 'iso' for the strict RFC-3339 / ISO-8601 format (aka 
"-MM-dd'T'HH:mm:ssX")


 - 'intl' for the relaxed RFC-3339 using the space separator (aka 
"-MM-dd HH:mm:ssX")


 - 'standard' for the same format, with a space separator but without 
timezone (aka "-MM-dd HH:mm:ss"). I thought of 'local', but it seems 
rather inappropriate for a locale independent format. If you have 
another proposal...



  Claude



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org