You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Marinó A. Jónsson" <ma...@centrum.is> on 2004/03/12 21:39:43 UTC
veltools v1.1 and v1.2
I've been testing the struts examples with the new Struts version and some
things caught my attention ...
StrutsUtils.getActionErrors(HttpServletRequest) should really be deprecated
in veltools v1.1 and a new method introduced that returns ActionMessages
instead of ActionErrors (see Struts App 2).
that said,
JSP versions of App 1 and App 5 fail and need to be upgraded (for veltools
v1.2).
Other apps seem to work fine with Struts v1.2 :)
cheers,
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: veltools v1.1 and v1.2
Posted by Mike Kienenberger <mk...@alaska.net>.
Nathan Bubna <na...@esha.com> wrote:
> Marin� A. J�nsson said:
> > I've been testing the struts examples with the new Struts version and
some
> > things caught my attention ...
> >
> > StrutsUtils.getActionErrors(HttpServletRequest) should really be
deprecated
> > in veltools v1.1 and a new method introduced that returns ActionMessages
> > instead of ActionErrors (see Struts App 2).
>
> hmm. that's a tough deprecation/migration to make. it would mean giving
up
> the method name since we can't have to methods with the same name and
> signature, but different return types.
>
> and since ActionErrors isn't deprecated (even in struts HEAD), i'm not
sure i
> see reason to do this.
I seem to recall that ActionErrors have been defacto-ly (sic) deprecated
from postings I've seen to the struts dev mailing list. I think struts is
facing the same technical limitation that you see above in deprecating them.
However, those who ask are being told to use ActionMessages instead of
ActionErrors.
I haven't seen the code in question, but couldn't you use
getActionMessages(HttpServletRequest)?
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: veltools v1.1 and v1.2
Posted by Tim Colson <tc...@cisco.com>.
> we deprecated both
> of those and went with getErrors() and getMessages()?
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: veltools v1.1 and v1.2
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
kewl :)
> -----Original Message-----
> From: Nathan Bubna [mailto:nathan@esha.com]
> Sent: 12. mars 2004 23:32
> To: Velocity Developers List
> Subject: Re: veltools v1.1 and v1.2
>
>
> Marinó A. Jónsson said:
> > > ok, now the real question is: do we start this migration
> in 1.1 or
> > > in 1.2? and if we start with 1.1, then does this little change
> > > warrant a second RC?
> > >
> > > i'm leaning toward answering "1.1" and "no", but i could
> be easily
> > > influenced on these.
> >
> > IMO we should definitely start in 1.1 ... I'm not sure if
> it warrants
> > a second RC though. What is the tradition? - should a release, in
> > effect, be the same as the last RC, or is it ok to make
> minor changes
> > in between? (I say _minor_ since these are only deprecations - they
> > don't make a real impact until v1.2 or v1.3).
>
> i think deprecating in 1.1 should be fine. these are
> primarily internally used methods. it's not likely that
> people are developing against them. also,
> getActionMessages() hasn't been in a final release (though
> it's been around a while). so, given the extreme simplicity
> (incredibly unlikely to introduce a
> bug) and low impact (just deprecations) of the change, then
> we shouldn't need to do another RC.
>
> also, because these are largely internal-use methods, i think
> we should go ahead and remove them in 1.2. there's no good
> reason to keep them around.
>
> i'll check these changes in shortly.
>
> 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
Re: veltools v1.1 and v1.2
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
> > ok, now the real question is: do we start this migration in
> > 1.1 or in 1.2? and if we start with 1.1, then does this
> > little change warrant a second RC?
> >
> > i'm leaning toward answering "1.1" and "no", but i could be
> > easily influenced on these.
>
> IMO we should definitely start in 1.1 ... I'm not sure if it warrants a
> second RC though. What is the tradition? - should a release, in effect, be
> the same as the last RC, or is it ok to make minor changes in between? (I
> say _minor_ since these are only deprecations - they don't make a real
> impact until v1.2 or v1.3).
i think deprecating in 1.1 should be fine. these are primarily internally
used methods. it's not likely that people are developing against them. also,
getActionMessages() hasn't been in a final release (though it's been around a
while). so, given the extreme simplicity (incredibly unlikely to introduce a
bug) and low impact (just deprecations) of the change, then we shouldn't need
to do another RC.
also, because these are largely internal-use methods, i think we should go
ahead and remove them in 1.2. there's no good reason to keep them around.
i'll check these changes in shortly.
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: veltools v1.1 and v1.2
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Mar 12, 2004, at 6:16 PM, Marinó A. Jónsson wrote:
>> ok, now the real question is: do we start this migration in
>> 1.1 or in 1.2? and if we start with 1.1, then does this
>> little change warrant a second RC?
>>
>> i'm leaning toward answering "1.1" and "no", but i could be
>> easily influenced on these.
>
> IMO we should definitely start in 1.1 ... I'm not sure if it warrants a
> second RC though. What is the tradition? - should a release, in
> effect, be
> the same as the last RC, or is it ok to make minor changes in between?
> (I
> say _minor_ since these are only deprecations - they don't make a real
> impact until v1.2 or v1.3).
I would do a rc2 and note in the changelog the difference. However,
since it's just a deprecation, I wouldn't let it change your plan for
release.
geir
>
> Marinó
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: veltools v1.1 and v1.2
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
> ok, now the real question is: do we start this migration in
> 1.1 or in 1.2? and if we start with 1.1, then does this
> little change warrant a second RC?
>
> i'm leaning toward answering "1.1" and "no", but i could be
> easily influenced on these.
IMO we should definitely start in 1.1 ... I'm not sure if it warrants a
second RC though. What is the tradition? - should a release, in effect, be
the same as the last RC, or is it ok to make minor changes in between? (I
say _minor_ since these are only deprecations - they don't make a real
impact until v1.2 or v1.3).
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: veltools v1.1 and v1.2
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
> > Nathan Bubna said:
> > > > Marinó A. Jónsson said:
> > > > > StrutsUtils.getActionErrors(HttpServletRequest) should
> > > > > really be deprecated in veltools v1.1 and a new method
> > > > > introduced that returns
> > > > > ActionMessages instead of ActionErrors (see Struts App 2).
...
> > it would annoy me to have a different naming pattern than
> > getActionMessages(). what if we deprecated both of those and
> > went with getErrors() and getMessages()? this would be sort
> > of complementary to the saveErrors() and saveMessages() in
> > Struts actions. if they don't need the word "Action" in the
> > name, why should we? :)
>
> me likes :)
>
> +1
>
ok, now the real question is: do we start this migration in 1.1 or in 1.2?
and if we start with 1.1, then does this little change warrant a second RC?
i'm leaning toward answering "1.1" and "no", but i could be easily influenced
on these.
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: veltools v1.1 and v1.2
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
me likes :)
+1
> -----Original Message-----
> From: Nathan Bubna [mailto:nathan@esha.com]
> Sent: 12. mars 2004 22:18
> To: Velocity Developers List
> Subject: Re: veltools v1.1 and v1.2
>
>
> Marinó A. Jónsson said:
> > > > StrutsUtils.getActionErrors(HttpServletRequest) should
> really be
> > > > deprecated in veltools v1.1 and a new method introduced
> > > that returns
> > > > ActionMessages instead of ActionErrors (see Struts App 2).
> > >
> > > hmm. that's a tough deprecation/migration to make. it
> would mean
> > > giving up the method name since we can't have to methods with the
> > > same name and signature, but different return types.
> > >
> > > and since ActionErrors isn't deprecated (even in struts
> HEAD), i'm
> > > not sure i see reason to do this.
> >
> > I realize that the ActionErrors class per se is not being
> deprecated
> > ... but if you take a look at Struts RequestUtils (or
> rather TagUtils)
> > you'll see that getActionErrors(PageContext, String) is
> being removed
> > after v1.2. So this seems to be the general direction the
> Struts team
> > is moving in.
> ...
>
> well, we shouldn't just drop the method, and it would annoy
> me to have a different naming pattern than
> getActionMessages(). what if we deprecated both of those and
> went with getErrors() and getMessages()? this would be sort
> of complementary to the saveErrors() and saveMessages() in
> Struts actions. if they don't need the word "Action" in the
> name, why should we? :)
>
> 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
Re: veltools v1.1 and v1.2
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
> > > StrutsUtils.getActionErrors(HttpServletRequest) should really be
> > > deprecated in veltools v1.1 and a new method introduced
> > that returns
> > > ActionMessages instead of ActionErrors (see Struts App 2).
> >
> > hmm. that's a tough deprecation/migration to make. it would
> > mean giving up the method name since we can't have to methods
> > with the same name and signature, but different return types.
> >
> > and since ActionErrors isn't deprecated (even in struts
> > HEAD), i'm not sure i see reason to do this.
>
> I realize that the ActionErrors class per se is not being deprecated ... but
> if you take a look at Struts RequestUtils (or rather TagUtils) you'll see
> that getActionErrors(PageContext, String) is being removed after v1.2. So
> this seems to be the general direction the Struts team is moving in.
...
well, we shouldn't just drop the method, and it would annoy me to have a
different naming pattern than getActionMessages(). what if we deprecated both
of those and went with getErrors() and getMessages()? this would be sort of
complementary to the saveErrors() and saveMessages() in Struts actions. if
they don't need the word "Action" in the name, why should we? :)
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: veltools v1.1 and v1.2
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
> > StrutsUtils.getActionErrors(HttpServletRequest) should really be
> > deprecated in veltools v1.1 and a new method introduced
> that returns
> > ActionMessages instead of ActionErrors (see Struts App 2).
>
> hmm. that's a tough deprecation/migration to make. it would
> mean giving up the method name since we can't have to methods
> with the same name and signature, but different return types.
>
> and since ActionErrors isn't deprecated (even in struts
> HEAD), i'm not sure i see reason to do this.
I realize that the ActionErrors class per se is not being deprecated ... but
if you take a look at Struts RequestUtils (or rather TagUtils) you'll see
that getActionErrors(PageContext, String) is being removed after v1.2. So
this seems to be the general direction the Struts team is moving in.
> > that said,
> >
> > JSP versions of App 1 and App 5 fail and need to be upgraded (for
> > veltools v1.2).
>
> noted. though i won't have time to work on this in the
> foreseeable future.
I'll be happy to do the necessary changes when the time comes (they are
_very_ minor).
> > Other apps seem to work fine with Struts v1.2 :)
>
> cool. but remember, Struts has switched to Tomcat-style
> versioning. 1.2.0 is really just an alpha unless/until the
> community decides otherwise.
heh, yeah, I know ... I think they're now on 1.2.1 :)
cheers,
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: veltools v1.1 and v1.2
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
> I've been testing the struts examples with the new Struts version and some
> things caught my attention ...
>
> StrutsUtils.getActionErrors(HttpServletRequest) should really be deprecated
> in veltools v1.1 and a new method introduced that returns ActionMessages
> instead of ActionErrors (see Struts App 2).
hmm. that's a tough deprecation/migration to make. it would mean giving up
the method name since we can't have to methods with the same name and
signature, but different return types.
and since ActionErrors isn't deprecated (even in struts HEAD), i'm not sure i
see reason to do this.
> that said,
>
> JSP versions of App 1 and App 5 fail and need to be upgraded (for veltools
> v1.2).
noted. though i won't have time to work on this in the foreseeable future.
> Other apps seem to work fine with Struts v1.2 :)
cool. but remember, Struts has switched to Tomcat-style versioning. 1.2.0 is
really just an alpha unless/until the community decides otherwise.
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