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/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to