There's a "conditional behavior" use case in the existing code as well; when validation fails, we want to redisplay the input form. Originally, I modelled this command as a Chain that conditionally executed its child commands, but that seemed a little hokey. Now, this command definition says:
<command className="org.apache.struts.chain.servlet.ValidateActionForm" failureCommand="servlet-validation-failure"/>
so I'm declaring the name of another chain to go execute if validation fails. The actual code that does the conditional execution looks like this (in the abstract base class):
I should've seen that, but didn't look hard enough. That's pretty cool. I guess, due to the way digester works, it doesn't have to be called "failureCommand" for my case. For Tiles, I could provide any number of attributes like that, right?
I suspect there is a lot of useful refactoring to be had in order to employ chain underneath something like Tiles;
I bet you're right. For now, I'm just pasting existing functionality inline to make sure I understand how it works and what it's doing. That's why I'm reluctant to submit it yet. I'd hate to submit something that gets committed and locks us into an approach when refactoring would produce something better. I'll look at it some more.
perhaps the best approach for development might be to go ahead and let TilesPlugIn configure things the way it wants, but add your own plugin (running after the Tiles one) to replace the configured RequestProcessor for executing your chain(s) instead.
The problem is that TilesPlugin throws an exception and doesn't configure anything if your RequestProcessor is not a TilesRequestProcessor. So we'd really have to replace it with something that doesn't do that.
Thanks for the suggestions -- especially on the conditional processing thing. I'll take a good look at that.
Greg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
