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
#)

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

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
)
>>
>>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 (AT) struts (DOT) apache.org
>For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

At 9:07 AM +0100 6/30/06, Phil Zoio wrote:
>Joe,
>
>Could Struts 1.3 set up to have a separate chain per module?

Phil: I thought we discussed this two weeks ago. In short, the
answer is "yes". Looking back at what I wrote, perhaps I gave too
much detail at the wrong time. Here is the core of it:

>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.

For context, Struts uses commons-chain code to instantiate a universe
of catalogs which contain commands. You'd use the <controllerto
specify the name of a catalog and the name of a command within that
catalog which is to be executed to process the request. Therefore,
you could specify different "bootstrap" commands for each controller
until you turn blue.

Joe

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.

6/30/06, Phil Zoio <philip.zoio (AT) iogloballtd (DOT) comwrote:
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
#)

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: URL
>For additional commands, e-mail: URL
>
>>
>>
>>
>
>
>
>
global limited, Registered in England No. 05269056 Reg. : G10 B83 Columba House, Martlesham Heath, Ipswich, Suffolk. IP5 3RE

This electronic message contains information from 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&E

To unsubscribe, e-mail: URL
For additional commands, e-mail: URL
--