struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <...@Germuska.com>
Subject RE: sTRUTS 1.3 - chain flow
Date Fri, 20 May 2005 14:10:30 GMT
At 2:43 PM +0100 5/20/05, Marco Mistroni wrote:
>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 have time to try this, let me know -- but I'd be afraid that 
if you defined another catalog with the name "struts", it would 
overwrite the base "struts" catalog instead of merging with it.  If 
that's true, then you either must edit the one chain-config.xml which 
defines the catalog named "struts" or we would have to specify a 
different catalog name for this lookup.  Perhaps we should just 
choose "struts.local" or something.  This would allow users to add 
preprocessing behavior without touching the base chain-config.xml, 
although it doesn't address the other case of mixing commands within 
the two main chains -- for the moment, I don't see any road to 
solving that which isn't a lot more work than it's worth, since I 
feel that users who are choosing to change the core chains are "power 
users" -- however, the "preprocessing" seems a bit more appropriate 
to expose to "less powerful" users.

>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&param2=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&param2=y).

I don't understand how adding parameters to the request path once the 
Servlet is already processing it could possibly work; does the 
pre-existing code perform a redirect after manipulating the path? 
Furthermore, I would think that, at least in SelectAction, if you 
change the path in that way, it would never find the right Action, 
because the "getPath" method is really just returning a key for the 
map of ActionConfig objects -- and changing the key would result in a 
failed lookup.

I must admit that I've never looked at the strutsws project, so I may 
have more questions than answers.  Is the idea that the same action 
can respond to a WebServices request as to a browser HTTP request? 
If that's the case, then you shouldn't need to change SelectAction -- 
because the same action can "handle" everything.  However, you may 
need to add in new commands or override existing ones so that by the 
time the Action is executed, the ActionContext has been populated the 
same way, whether the request came from one source or the other. 
Thus, isn't the place to change things more like PopulateActionForm? 
Don't bother with a whole redirect -- if you know how to construct a 
new URL, then you could just as easily create a map and use 
BeanUtils.populate(ActionForm, Map) -- then when the Action operates, 
it has no concern for which method was used to invoke the request. 
It just trusts that the ActionForm has the right data.

Now, I'm not sure how the response works -- so maybe you want one 
action (perhaps in preprocess) which simply sets a flag in the 
ActionContext:

context.put("webService", new Boolean(isWebService(request));

Then any later commands could simply test that context value to know 
when they need to operate in a different way to accommodate the 
differences of web services.

Is this making sense?  Without a better handle on the details of 
strutsws, I won't be much more help, but unfortunately I don't have 
time to make a big study of that right now.


>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


-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

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


Mime
View raw message