That's exactly what Struts 2 does with interceptors, and S2 takes it a step farther by allowing each action to have its own sequence, if you like.
An important question is whether we want to stick with Chain in the Struts 1.x series or consider moving to Interceptors for Struts 1.4. I didn't understand interceptors when we started the Commons Chain work, but now that I do, it looks like we reinvented the wheel. -Ted. On 6/30/06, Phil Zoio <[EMAIL PROTECTED]> wrote:
Joe, Could Struts 1.3 set up to have a separate chain per module? Suppose you wanted to partition your app so that certain parts use one chain configuration and other parts use another. In 1.2 you'd use separate subclasses of RequestProcessor. With Struts 1.3, ideally you should be able to use separate chains. You could for example build a lightweight chain to handle parts of the application with specific performance requirements, and the standard chain for other parts. Bearing in mind that a chain is a pretty lightweight object - there will only be one instance of each command in memory per chain. Any module would by default get the basic pre-supplied chain configuration. However, you would be able to override this using a web.xml entry in the same way that you set up modules. Phil > Joe Germuska wrote: > >> At 9:09 PM +0100 6/14/06, Phil Zoio wrote: >> >>> I can't comment on how people are actually using it, but changing >>> the request processor workflow on a per module basis is quite easy >>> with Struts 1.2. Assuming that this is something which some people >>> are doing, then it would seem to make sense to support this for >>> Struts 1.3 as well, at least for the interests of consistency with >>> previous versions, especially if the 1.2 request processor has been >>> earmarked for deprecation. >> >> >> >> Phil: >> >> Have you looked at what is required to change the workflow in Struts >> 1.3 on a per-module basis? Can you point out where you think it's >> unnecessarily complicated? Do you have any ideas about how to do it >> differently? >> >> Joe >> >> >>> At 9:23 PM +0100 6/13/06, Phil Zoio wrote: >>> >>>> Is it possible to have multiple chain configurations for the same >>>> Struts 1.3 app. For example, can you configure one module to use >>>> tiles and another to not do so? >>> >>> >>> >>> >>> It is technically possible to change which command is looked up in >>> the catalogs and executed to process the request as part of the >>> controller-config on per-module basis. However, you'd need to go >>> to some greater lengths to define the necessary commands and >>> catalogs, because the distributed chain-config.xml in both >>> struts-core and struts-tiles use the same catalog name. The idea >>> was to minimize the places where a user would need to change >>> configurations to use Tiles. >> >> >> >>> >>> For the specific case you cite, there's really no need to do >>> anything special, since if you are using the Tiles request >>> processing chain, nothing prevents you from using ActionForwards >>> which do not point to tiles paths intermixed with those which do. >>> Just use the chain-config packaged in struts-tiles (as indicated at >>> http://wiki.apache.org/struts/StrutsUpgradeNotes12to13#head-dfc970a4614f0305c8ac31f1d08fbdfcdd666b5d) >>> >>> >>> If people end up doing a lot of mixing and matching of chain >>> catalogs, we would want to make this easier than it is now, but so >>> far we just don't know enough about if or how people are likely to >>> want to do this, so it's hard to know how to make it easier. >>> >> >>> Joe >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> >> > > iO global limited, Registered in England No. 05269056 Reg. Offices: G10 B83 Columba House, Martlesham Heath, Ipswich, Suffolk. IP5 3RE This electronic message contains information from iO global limited which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. This email does not constitute a contract. E&OE --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- HTH, Ted. * http://www.husted.com/struts/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
