On 5/4/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
On 5/4/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
>
> At 8:07 AM -0700 5/4/06, Michael Jouravlev wrote:
> >Looking at 1.3 internals (at last) I've found that it contains both
> >ComposableRequestProcessor (CRP) and legacy RequestProcessor (RP). Is
> >this duality really needed?
> >
> >For a regular Struts user who does not extend RP, the new CRP should
> >work just like the old one. The only difference is the config files.
> >
> >Dragging legacy RP along seems like a burden to me, especially that
> >the main difference between 1.2 and 1.3 is the chain of commands, so
> >unless someone wants to make explicit use of chain, there is no reason
> >to upgrade to 1.3. In future, the RP will either have to be supported
> >all along (is it reasonable?) or deprecated (why not do it now?).
> >
> >Am I not getting something?
>
> You're right that chain is the main new feature, but there are others
> that have not been backported to 1.2 (arbitrary properties on all
> config objects is a nice one) and I doubt there's any interest at all
> in that backporting.
>
> I would be OK with deprecating RequestProcessor.
Me too.
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
--
Martin Cooper
I've been concerned
> about people using older subclasses of RequestProcessor (like for
> SSLExt or even Tiles) and then not understanding how using that makes
> the chain non-functional.
>
> Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
