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
Joe - I haven't yet - I will need to understand the mechanism you are
talking about a bit better. I'm still not very familiar with commons chain.
Phil
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
