6 May
2008
6 May
'08
4:17 p.m.
Hi devs,
I'd like to enable some classes from the commons-lang library as
velocity tools.
As a reminder, a velocity tool is an object that is placed in the
velocity context, and which can be used to perform some actions. The
tool should be stateless and thread-safe, as the same object is used for
all requests. There is the VelocityTools library, which contains some
useful tools, but I think those are not enough.
So, I'd like to enable StringUtils, WordUtils, RandomStringUtils,
StringEscapeUtils, BooleanUtils, ArrayUtils, math.NumberUtils,
math.RandomUtils, time.DateUtils, time.DateFormatUtils
Given the fact that tools are only create once, there won't be any
memory issue. And I think that these tools are wide enough to discourage
any attempt to add nice methods to the XWiki class, and will allow to
deprecate utility methods in the XWiki API, and remove the Util API.
Any objections? Any other classes we should enable?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
6 May
6 May
9:18 p.m.
On May 6, 2008, at 4:17 PM, Sergiu Dumitriu wrote:
Hi devs,
I'd like to enable some classes from the commons-lang library as
velocity tools.
As a reminder, a velocity tool is an object that is placed in the
velocity context, and which can be used to perform some actions. The
tool should be stateless and thread-safe, as the same object is used
for
all requests. There is the VelocityTools library, which contains some
useful tools, but I think those are not enough.
So, I'd like to enable StringUtils, WordUtils, RandomStringUtils,
StringEscapeUtils, BooleanUtils, ArrayUtils, math.NumberUtils,
math.RandomUtils, time.DateUtils, time.DateFormatUtils
I'm +1 generally. We need to decide if we keep both datetool and
dateutils for ex though. Same for ArrayUtils vs ArrayTool, etc.
Given the fact that tools are only create once, there
won't be any
memory issue. And I think that these tools are wide enough to
discourage
any attempt to add nice methods to the XWiki class, and will allow to
deprecate utility methods in the XWiki API, and remove the Util API.
Any objections? Any other classes we should enable?
Thanks
-Vincent
14 May
14 May
7:37 p.m.
Vincent Massol wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On May 6, 2008, at 4:17 PM, Sergiu Dumitriu wrote:
Although I am against having 2 tools with the same target, I think that
we should keep both ListTool and ArrayUtils. ArrayUtils is supposed to
be used from java, while ListTool is supposed to fix some shortcommings
of the velocity language (cannot properly handle java arrays). ListTool
adds set and get for java arrays. We could drop the need for this tool
completely using an ArrayHelperUberspector.
Regarding the DateTool and DateUtils, again, DateUtils does not have a
method for creating a date or calendar object. And we also have the
jodatime plugin for manipulating dates, also. I'd rather use the
jodatime plugin for all our "dating" needs :p. I really don't know which
of these 3 tools to use. Help?
I prefer NumberUtils instead of NumberTool.
EscapeTool and StringEscapeUtils both have methods for escaping strings.
SEU has escapeCsv, ET has escapeUrl; SEU has unescape methods, ET has
special velocity symbols, like getDollar, getBackslash, getHash...
Bottom line, we need both.
Another issue is the name of the velocity variables for these. Isn't
escapetool a bit too long? I'd drop the tool part where the remaining
name does not cause conflicts, so that we would have:
$escape
$escapeUtils
$alternator
$iterator
$sort
$math
$arrayUtils
$booleanUtils
$numberUtils
$stringUtils
$wordUtils
$dateUtils
$dateFormatUtils
$durationFormatUtils
$randomStringUtils
$randomNumberUtils (we can consider booleans as numbers, too)
WDYT?
Hi devs,
I'd like to enable some classes from the commons-lang library as
velocity tools.
As a reminder, a velocity tool is an object that is placed in the
velocity context, and which can be used to perform some actions. The
tool should be stateless and thread-safe, as the same object is used
for
all requests. There is the VelocityTools library, which contains some
useful tools, but I think those are not enough.
So, I'd like to enable StringUtils, WordUtils, RandomStringUtils,
StringEscapeUtils, BooleanUtils, ArrayUtils, math.NumberUtils,
math.RandomUtils, time.DateUtils, time.DateFormatUtils
I'm +1 generally. We need to decide if we keep both datetool and
dateutils for ex though. Same for ArrayUtils vs ArrayTool, etc.
Given the fact
that tools are only create once, there won't be any
memory issue. And I think that these tools are wide enough to
discourage
any attempt to add nice methods to the XWiki class, and will allow to
deprecate utility methods in the XWiki API, and remove the Util API.
Any objections? Any other classes we should enable?
Thanks
-Vincent
6022
days inactive
6030
days old
2 comments
2 participants
participants (2)
-
Sergiu Dumitriu -
Vincent Massol