<SNIP>Anyway, from my personal experience, when one wants to apply control
logic that is common to various requests (as opposed to based in a
single Action), the chain based request processor has made that
simpler for me.</SNIP>
This is hard for me to follow. I am not sure what "control logic that is common to various request" would be, so I cannot see how the "composable request processor" (I like that way of talking about it) helps here.
Good, since that's its class name!
Here are the examples of custom commands I used in a project built around the 1.2 version of struts-chain, sprinkled through the chain:
* set the request character encoding to UTF-8 (sure, I could have used a filter for this, but I didn't!)
* see if there is a request parameter with a specific name to proxy for a normal login process (only for testing use) and if found, put that value in the context
* retrieve the user's ID from an HTTP Request Header set by 3rd party auth. software and put it in the context (for normal production use)
* independent of where the user's ID came from (see two previous commands), ensure that there is a "User" in the session and initialize the session as appropriate
(insert standard struts form processing here)
* Alternative per-action authorization since role-based doesn't work for this app
* set up an ActionContext object (similar to but different from what is now in Struts)
(insert standard struts action processing here)
* do some standard post-processing with the ActionContext
* look up a bit of "page preparation" logic based on the tile used in the ActionForward and, if found, execute the logic (used to pre-fill forms from database and do other setup)
<SNIP>As for reusable extensions to the request processing cycle, I think we will find that building those is simpler too, once people start absorbing this. Some of the earliest discussions about needing a composable request processor came up in the context of the struts-workflow project, which faced a challenge in wanting to provide custom request processing and needing to figure out how to work with users who may or may not have wanted to use Tiles, since Tiles also required a subclass of RequestProcessor.</SNIP>
10-4! Is there going to be a mechanism for plugging extensions in at each stage in the final analysis? That would be ideal, to my mind.
Yes, I agree that this would be valuable. Ted made some suggestions today about one way we might approach this. At first review, I was ambivalent about the details, but I'll look at them again. As I believe I've noted elsewhere, I like the model of Maven's "preGoal" and "postGoal". As more people start actually using the code, i'm sure we'll get even more suggestions about good ways to achieve this.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
