[xwiki-devs] [proposal] Enable some commons-lang classes as velocity tools
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/
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
Vincent Massol wrote:
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.
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?
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
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (2)
-
Sergiu Dumitriu -
Vincent Massol