On 11/17/2016 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. > > 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). > > 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). > > 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. > >
+1 for all of these, as long as they are deprecations, and not direct removals. -- Sergiu Dumitriu http://purl.org/net/sergiu --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
