Somewhere along the way in this discussion, simplicitly was lost. Configuring each method in struts-config and separating RP into many interfaces seems like overkill to me. You lose the ability to truly compose behavior with the struts-config approach. You can't do this in xml:
public processActionCreate() { super(); //do parent behavior tilesRP.processActionCreate(); // do tiles // do some custom stuff someotherRP.processActionCreate(); }
David
No, but you can write a trivial DavidGrahamActionCreateProcessor which implements that method and gets configured in the code.
I don't want to put words in your mouth, but from the discussion, I get the sense that you are focused on deploying a single application. The people who are speaking up here are all those who are trying to write libraries that could be used in any Struts application -- the Workflow extension, for example, or internally here, a "survey" application. What if you wanted to include my survey library in an application which also used the Workflow, and you need to use Tiles but neither of us designed using the TilesRequestProcessor?
Speaking of the TilesRequestProcessor, this little chunk of code is going to be problematic:
protected void initRequestProcessorClass(ModuleConfig config) throws ServletException
{
[--snip--]
// Check if specified request processor is compatible with Tiles.
Class tilesProcessorClass = TilesRequestProcessor.class;
if(!tilesProcessorClass.isAssignableFrom(configProcessorClass))
{ // Not compatible
String msg = "TilesPlugin : Specified RequestProcessor not compatible with TilesRequestProcessor";
if (log.isFatalEnabled())
{
log.fatal(msg);
}
throw new ServletException(msg);
} // end if
}
(See TilesPlugIn, line 351).
Joe
--
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
