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