Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0
Message-Id: <a06230938c0b620ca99be@[192.168.1.103]>
In-Reply-To: <44906CE7.9010408@realsolve.co.uk>
References: 
 <19574377.1150212538979.JavaMail.os-j2ee@opensymphony01.managed.contegix.c
 om> <448F1EDA.9090802@realsolve.co.uk>
 <a06230921c0b4d82e94c7@[192.168.1.103]> <44906CE7.9010408@realsolve.co.uk>
Date: Wed, 14 Jun 2006 15:25:07 -0500
To: Struts Developers List <dev@struts.apache.org>
From: Joe Germuska <Joe@Germuska.com>
Subject: Re: Struts 1.3.x: Using multiple chain configurations
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

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


>Phil
>
>
>Joe Germuska wrote:
>
>>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: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org


-- 
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com    

"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
	-- Robert Moog

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org