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?
Yes ... the attribute names just have to match up with the JavaBeans property names on your Command implementation classes (we're using Digester's "Set Property Rule").
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.
I've found that experimenting has worked a lot better once I started doing it in the open :-).
Seriously, as long as we play in the contrib/struts-chain directory, people will understand that this is an actively developing idea, not a stable framework on which to build apps -- at least not yet. We're all learning how to apply the chain concepts, and working out what design patterns and idioms make the most sense. It'll go better for everyone if we share that learning experience; and it's more fun to boot.
That's a long winded way of saying I'd welcome the work you're doing being part of the contrib/struts-chain package, if you'd like.
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
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
