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:
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.
- 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.
- This bean would be scoped at least to "application", "request", and "session". Once Shale nails down the "dialog" scope, we "steal" it from them.
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.
Don
Joe Germuska wrote:
At 10:52 AM -0800 2/14/05, Don Brown wrote:
and "process-pojo" could string together some of the same commands, but deal differently with the various special cases. Exactly how we would determine the need to branch would be open for discussion.
This is, in fact, what I do today - replace several Struts chain commands, however since we are talking about the "future" of actions, I thought this might be a good opportunity have Struts do it "right" the first time. :)
I'm all for that -- but I'm not clear what you'd do to "do it right." Are you cool with two parallel "process-*" chains? If you *replace* commands, then presumably your apps wouldn't be backwards compatible with Struts 1.2 apps.
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
