I think there are two questions we have to answer:
1. What is the best approach for request-specific logic code?
2. How can we integrate that into our current code base while maintaining backward compatibility?
To me, we need to have clearly solved 1 before tackling 2. My answer for the first question:
If we can have parallel processing chains, then I don't think that's necessarily true. But if we can solve it without getting stuck in the mud, then great!
A POJO "backing bean" that is basically a port of the JSF backing bean.
- This bean wouldn't be required to extend or implement anything.
- It would support setters that would be called by the outside framework
- It would support multiple "execute" methods that could be any name. These methods would take no arguments but could retrieve ActionContext via ActionContext.getInstance() similar to WW2 and JSF. I suppose it also could be argued they should take ActionContext as the sole parameter similar to how Tapestry works.
I'm not sure I see value in both; it just adds more code and more doc, without being likely to add clarity.
- First level validation would be handled through commons-validator as we do now. Second level, the one where validate() code would be another specified method, defined in the action mapping or method annotation.
OK, so we update ActionConfig to have "validateMethod" and "actionMethod" instead of just "method"? I don't really love continuing to stick things on the <action> element, but I suppose it's not the end of the world. Of course, we could also start using the arbitrary Properties object which ActionConfig now has.
- This bean would be scoped at least to "application", "request", and "session". Once Shale nails down the "dialog" scope, we "steal" it from them.
I like this general idea; we'd want an application-scoped "expert" who knew how to deal with multiple scopes. Perhaps this is a good starting point for a "Struts API" bean, which would have a method, "findAttribute(String scope, String name, ActionContext context)" ?
Where we are at, as a group, is discussing the answer to 1. This is my vision, but I fully expect it to be dissected and rejected, at least in part, in the process of gaining group consensus.
Only once we gain consensus can we begin to address 2, and at this stage, I think we still have a ways to go. What we can agree on, however, is whatever solution and subsequent implementation we choose, it will have to be 100% backwards-compatible with Struts 1.2.
See above; I am not convinced of the order, but welcome the discussion. I don't see how any of the POJO changes would be implemented in a way which had any impact on the familiar Struts classes; they'd each have to be handled as special cases, wouldn't they?
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]
