Re: [tools] Tools reeng
+1 deprecate and refactor away. this all sounds good. On Thu, Nov 17, 2016 at 10:32 AM, Sergiu Dumitriu wrote: > 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 > >
Re: [tools] Tools reeng
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
Re: [tools] Tools reeng
On 17/11/2016 19:10, Mike Kienenberger wrote: On Thu, Nov 17, 2016 at 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: - 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. Tools are lightweight and often trivial in implementation. I see nothing wrong with a single method on a tool. Except maybe the proliferation of standard tools, not very pleasant for newcomers. If the tool is appropriately-named, other functionality may be added later. Yes. That's why merging toStrings() and sort() in a CollectionTool seems more appropriate to me. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: [tools] Tools reeng
On Thu, Nov 17, 2016 at 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: > - 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. Tools are lightweight and often trivial in implementation. I see nothing wrong with a single method on a tool. If the tool is appropriately-named, other functionality may be added later. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[tools] Tools reeng
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. Claude - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
