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 17:24:35 GMT
>However, just to level-set as far as the current 1.2.x version goes...

Thanks, Frank.  That helps a lot.

I do think that it would be much easier in 1.3 than in 1.2 to solve 
this without doing a forward and re-engaging the request processor; I 
can see where the complexity of intervening in arbitrary spots in the 
request process in the "template pattern" approach of the 
RequestProcessor might make the forward a more attractive solution, 
but that is one of the issues solved by composing the request 
processing logic out of a number of small commands.

I'd suggest adding a preprocessing command which recognizes the SOAP 
header, as Frank described, and instead of forwarding, simply sets a 
key/value pair in the ActionContext which other commands can 
interpret.  Then later, you could extend the PopulateForm class to 
look for the flag and to do its population process based on SOAP data 
instead of request parameters.

I'm curious, how does strutsws deal with the response?  Is it assumed 
that all of these requests are actually only ever serving SOAP 
clients, so that the response is always a SOAP response?  Or is the 
goal to have one action function for both simple HTTP requests as 
well as SOAP requests?  If it's the first, then you have nothing else 
to do; however, if you were interested in the second... well, I 
suppose you could put something in after the ExecuteAction stage or 
at the beginning of the process-view chain which consulted the 
resulting ForwardConfig and, if in "SOAP mode", looked up a different 
ForwardConfig.  Now that you can put arbitrary properties in a 
ForwardConfig, you could even configure it in-place:

<action path="/SoapOrHttpDoesntMatter"
                type="com.example.ProcessRequestAction"
                name="FormBeanName">
     <forward name="success" path="/NormalResponse.jsp">
        <set-property key="SOAP.path" value="/SOAPResponseTemplate.jsp" />
    </forward>
</action>

and then this command early in the process-view chain:

public class AdjustForwardConfigForSoap extends ActionCommandBase {

    public boolean execute( ActionContext ctx ) {

        if (ctx.containsKey("SOAPModeFlat")) {
             ForwardConfig fc = ctx.getForwardConfig();
             String alternatePath = fc.getProperty("SOAP.path");
             if (alternatePath == null) throw new IllegalStateException();
             ForwardConfig alt = new ForwardConfig();
             alt.setPath(alternatePath);
             ctx.setForwardConfig(alt);
        }
   }
}

Typical caveats apply, but I think that would handle it.  I'm not 
totally sure how I feel about a practice of changing the forward 
config in the process-view chain, but I can't see any other way you'd 
handle it without having to bind your code a lot more to the specific 
fact that it might be used in both ways.

Joe

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