Re: request Processor in struts-2.
What I like about Chain is that it allows the "step-by-step" definition needed for request processing (ala the Template Method); with the loose coupling provided by CoR and Command patterns. Joe Germuska wrote: There are thousands of lines of discussion on this in the mailing list archives, if you really want to get into it. The earliest discussions I have hanging around in my archives are May 2003, but they may go back even further. 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 NiallI 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: request Processor in struts-2.
There are thousands of lines of discussion on this in the mailing list archives, if you really want to get into it. The earliest discussions I have hanging around in my archives are May 2003, but they may go back even further. 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 NiallI 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]
Re: request Processor in struts-2.
I am all for people downloading the nightly builds and acquainting themselves with the new designs in Struts (which is not Struts 2, by the way; it's Struts 1.3.0). But, I want to make sure that people understand -- this is code under rapid development; there are no API guarantees; and it may be a while before it's well documented. The source is wide open, and the lists are available for questions and criticisms -- but if you just want to use it and don't want to understand how it works, then you should probably wait for a regular release. It is really helpful to have people start building applications around the code -- nothing else provides the kind of testing necessary to really flush out issues -- but people who do this should be ready for periodic tweaking to respond to API changes and such until there's a full release. Joe At 9:45 AM + 2/9/05, Niall Pemberton wrote: 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 NiallI 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] -- 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]
RE: request Processor in struts-2.
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 NiallI 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]
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 NiallI 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]
request Processor in struts-2.
hi Thank You very much for ur help NiallI 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... On Wed, 9 Feb 2005 08:33:20 -, Niall Pemberton <[EMAIL PROTECTED]> wrote: > You can configure it using the element in the > struts-config.xml... > > http://struts.apache.org/userGuide/configuration.html#controller_config > > > > Niall > > - Original Message - > From: "Sandip Khetle" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, February 09, 2005 7:42 AM > Subject: request Processor in struts. > > > Hi > >Where do we make the entry for the request processor in > > struts application?for example I have extended the RequestProcessor > > class to create my > > MyRequestProcessor ...How do I communicate this to the > > application.Will i have to make any entry in some config > > file...? > > > > Thanks in advance > > > > -- > > Regards, > > SandipK > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Regards, Sandip Khetle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
