Ok, i've taken a little time this evening to look into Paul Barry's enhancement request for DateTool (bugzilla #23622). I feared that when i looked into ways to do this i would run into issues with the static methods that needed solving first, and sure enough, i was right...
To me, DateTool is not meant to be a static utility class. it ought to be an easily extendable tool for handling dates in web applications that often need to adapt the locale and timezone on a per-user or per-request basis. this would be most elegantly handled by extending the class to automatically garner from the session/request the locale and timezone info needed. having to passing the locale and timezone to the tool from the template with every format() call--as would necessarily be the case with a static utility--is definitely not elegant. so, with that said, it's time to admit that i did not think so clearly on the matter when first designing and submitting the tool, and i let a number of the methods be declared as static. now i very much want to de-staticize those methods. i see two options: 1. we just take the static declarations out. 2. we deprecate those methods, add non-static versions that now have to have different names and/or signatures, and eventually remove the static ones. let it be known that i despise option number two. if we go with #2, that means lots of annoying template updating. if we go with #1, all the templates still work, and only those few (if any at all) that used those static methods in java classes will have to do anything. frankly, i'd be surprised if anyone is using the static methods statically in java classes (obviously they can't be used statically in templates). i know standard practice for something like this in a java API is deprecate and replace, but these tools are really more of a velocity template API than they are a java API. the easier route is IMNSHO, to just take the static declarations out. i'd love to just do this unilaterally, but i think this one is worthy of a vote. it's lazy consensus, so speak soon (by next week at the latest) or forever hold your peace. p.s. i have some similar fears about this issue coming up again with MathTool and RenderTool. so far i don't see the static methods there as a problem, but that could change. thoughts? Nathan Bubna [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
