Hello Joe,
>As an aside, I think reveals an unfortunate (though minor)
>shortcoming of the basic chain model: either way, you must edit the
>struts chain-config.xml in order to use this behavior. I would
>prefer if there were a way for users to register their preprocessing
>command without having to extract the chain-config and edit it. That
>in itself isn't so bad, but it also makes it harder to track future
>changes in the chain-config.xml as distributed and integrate your
>local details with newer versions. It almost calls for an AOP-like
>configuration realm.
Hold on.... the 'editing' of chain config was my mistake because I
didn't want to have too many files while I was testing my app.
Now that I remember, in that famous article of Bill Siggelkow it was
explained how to 'override' chain processing by just specifying
The chain that you want to override..
In that case, I could just write my own custom-config.xml which contains
The chain servlet-preprocess (or whatever chain I want to override) and
Just declare it.. (like I have done in another very simple app), though
I don't know if this will solve problems that you have identified above.
>If you changed the behavior of
>org.apache.commons.chain.generic.LookupCommand, you would impact
>Struts in each of the places where it has a <lookup> element --
>looking up the preprocessing command, looking up the process-action
>chain, and looking up the process-view chain. That's probably not
>
yep, I have noticed it :-)
Sorry if I add another question..because there's something that has been
bothering me since I am trying to port my app to 1.3.
App was frank zammetti's strutsws, that allows to call Struts action
using
SOAP requests.
Without going into details, RequestProcessor.preProcess(), if identifies
an incoming XML request, it will extract those parameters and add them
to the URL (e.g. /myAction.do)
If the request was an XML request, it will extract the parameters from
the SOAP request, and produce a new URL /myAction.do?param1=x¶m2=y
I Have extended the SelectAction.getPath(Context ctx) command so that it
does exactly
What the original RequestPreprocessor.preProcess() was doing, so that
the path returned by getPath(Context ctx) will be
/myAction.do?param1=x¶m2=y).
But for some reasons, when the flow arrives to my ValidateActionForm
subclass (I have extended it to see what was happening) the two
parameters for the action form are still null.
If instead the request is not a SOAP request, the chain works as
normal, and it works just fine (forms get populated & action gets
executed).
So, I think I am missing one point (or I am not overriding the proper
methods).
Could you tell me what happens after SelectAction.getPath() gets
called? Where does the request go?
Because if I can find the part of the code that gets request parameters
and populate the form, maybe I can understand what's going on..
If it's not clear, I can mail you my class privately....
Thanx in advance for your reply
Regards
marco
thanx and regards
marco
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
