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 12:56:55 GMT
No, rather than changing LookupCommand, you would put your logic into 
one or more classes that are clean implementations of Command and 
configure in a catalog with a name so that the existing lookup 
command would find them -- either put them in catalog "struts"  under 
the name "servlet-standard-preprocess" or change the configuration of 
the lookup command to find them:
       <lookup
         catalogName="*your catalog*"
                name="*your command name*"
            optional="true"/>

You shouldn't need to change the behavior of LookupCommand itself -- 
you just need to give it the right information to do its job.

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.

Also, to clarify:

>And so, I will need to replace this entry in chain-config.xml
><define name= "lookup"
>             className= "org.apache.commons.chain.generic.LookupCommand"
>/>
>
>with
><define name= "lookup"
>             className= "com.myapp.commands.MyLookupCommand" />

This <define> element is just a bit of syntactic sugar that Craig 
came up with in the chain-config digesting process that allows you to 
do this once and then later have simpler configuration, say for 
example if you use a given command frequently.  It's comparable to 
the <taskdef> tag in Ant.  But again, the whole intention of the 
LookupCommand is that instead of changing its behavior, you point it 
at the other commands which you want executed.

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 
what you want.

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