On 5/5/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> From: Niall Pemberton <[EMAIL PROTECTED]>
> Date: May 5, 2006 2:36 PM
> Subject: Re: SAF 1.3.x and legacy RequestProcessor
>
> On 5/5/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
> > >Its probably academic, but since CRP extends RP then it seems
> > >incorrect to deprecate the whole class with a view to removing in the
> > >future. Wouldn't it be more correct to deprecate all the protected
> > >methods (e.g. processActionCreate(), processActionForm etc.)?
> > >
> > >Perhaps we should consider what the desirable end point is - IMO CRP
> > >becoming the RP seems like a good idea...so maybe the steps should be
> > >something like the following:
> > >
> > >1) Deprecate the protected methods in the RP.
> > >2) Remove RP deprecated methods and move the CRP logic into RP.
> > >Deprecate the CRP.
> > >3) Remove deprecated CRP.
Niall, do you suggest to have (1) in first release of 1.3, (2) in the
next release, and (3) yet another release? Because if the whole change
is implemented at once, why deprecating methods/classes before they
are removed? No one would have a chance to see them deprecated :-)
I understand that the step-by-step process makes sense primarily to
warn/inform users that a certain feature will be removed. But 1.3 has
not been released yet, so all steps can be done at once, cannot they?
The methods in the original RP have been there since Struts 1.1 - so
its not the case of these "not being released". Although CRP is the
default in Struts 1.3.x - theres nothing to stop users with a custom
RP from continuing to use it in Struts 1.3 and we should warn them
that these methods are going and that custom RP behaviour will need to
be re-implemented in Commands.
> For me the ideal end point is just a single RP and it seems cleaner to
> have it called RP than CRP. That would be my preference, but if others
> disagree and think that getting there is a PITA - its not a big deal.
Yes, I agree, having one rp called RP seems better to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
