Re: [tools] Tools reeng
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
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