In short, having RequestProcessor be a concrete class severely hampered the ability for people to make minor modifications to the request processing lifecycle. Furthermore, it made it nearly impossible for anyone to develop shareable libraries: the SSLExt and Workflow projects made brave efforts, but what if you wanted to use both in one project? It became clear that Struts needed to expose the request processing lifecycle more readily.
Furthermore, despite the problem of using more than one extension to the RequestProcessor, it became clear that the "Template Pattern" used in RequestProcessor was a way too rigid to allow certain kinds of changes. It imposed too strongly a specific idea of what steps would happen and in what order.
If you've never cared about changing your RequestProcessor, you can safely ignore everything about the CoR RequestProcessor, with the possible exception of if you want to use Tiles, in which case you'll simply have to specify an alternate chain-config, which will be something which we will write a simple HOWTO for.
But for people who have cared about changing the RequestProcessor, there seems to be a lot of enthusiasm and agreement that the CoR stuff is a good way to head.
Joe
At 7:30 PM +0530 2/9/05, <[EMAIL PROTECTED]> wrote:
Hi, It is not clear to me why CoR would be so special in the new Struts architecture. After reading the proposal it seems that the 3 types of controllers seem to be more interesting.
Was CoR chosen to leverage Commons Chain ? Why does a Web application need the flexibility of CoR ? I know that Swing uses it because the UI hierarchy is not simple.
Can't we just use Commons Chain with Struts with the same effect ? Do we have to design Struts itself based on CoR ?
At this point I haven't looked at any code. I am just trying to understand this particular design decision. I remember that Action chaining was discouraged.
Mohan
-----Original Message----- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 3:15 PM To: Struts Users Mailing List Subject: Re: request Processor in struts-2.
In Struts 1.2 you can configure different RequestProcessors for different modules, but you can' t have different RequestProcessors for the same module. Struts 1.3 (under development) is based on the Chain of Responsibilty (CoR) pattern (using Jakarta Commons Chain) - that introduces alot more flexibility in how you can configure "request processing". Sounds like it might be worth you downloading the "nightly" build and having a look at that.
Niall
----- Original Message ----- From: "Sandip Khetle" <[EMAIL PROTECTED]> Sent: Wednesday, February 09, 2005 9:25 AM
hi
Thank You very much for ur help Niall....I have one more question ......
Can we have multiple RequestProcessor classes for a single application .....I mean as we have a single ActionServlet is it mandatory to have a single RequestProcessor as well...?
thanks in advance...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
