Re: [tools] Tools reeng

[Claude Brisson]

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

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

[Nathan Bubna]

+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

[Sergiu Dumitriu]

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

[Claude Brisson]

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

[Mike Kienenberger]

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