You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Nathan Bubna <na...@esha.com> on 2003/10/15 08:00:34 UTC
[vote] remove static declarations from DateTool methods
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
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [vote] remove static declarations from DateTool methods
Posted by Ch...@dlr.de.
+1 on option 1, mee too :)
Cheers,
Christoph
Nathan Bubna wrote:
> 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
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
>
--
:) Christoph Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [vote] remove static declarations from DateTool methods
Posted by Claude Brisson <cl...@savoirweb.com>.
+1 on option 1
(contributor's vote...)
CloD
----- Original Message -----
From: "Marinó A. Jónsson" <ma...@centrum.is>
To: "'Velocity Developers List'" <ve...@jakarta.apache.org>
Sent: mercredi 15 octobre 2003 17:25
Subject: RE: [vote] remove static declarations from DateTool methods
+1 on option no. 1 :)
Marinó
> -----Original Message-----
> From: Nathan Bubna [mailto:nathan@esha.com]
> Sent: 15. október 2003 06:01
> To: velocity-dev@jakarta.apache.org
> Subject: [vote] remove static declarations from DateTool methods
>
>
> 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
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: [vote] remove static declarations from DateTool methods
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
+1 on option no. 1 :)
Marinó
> -----Original Message-----
> From: Nathan Bubna [mailto:nathan@esha.com]
> Sent: 15. október 2003 06:01
> To: velocity-dev@jakarta.apache.org
> Subject: [vote] remove static declarations from DateTool methods
>
>
> 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
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org