(As a point of order, the TODO item actually came first.) The main focus of the workflow proposal now is to create a generic framework that could be used in other environments; not just Struts. Most of the work here will initially take place in the Commons, with Struts implementation acting as a proof of concept. The high concept is be able to maintain state between requests, and perhaps forward a state to another user, and back again. Certain Struts specific behavior, like that mentioned by the TODO, may be necessary to implement the workflow, but that would be secondary. Personally, I think the wording of the TODO item is unfortunate, since "encoded" makes it sound like Actions should be performing the business lgoic. The usual advice is to create generic business logic classes that can be called from the Actions, and potentially from other environments (e.g. an Applet). In general, I would say that the generic business logic classes (or beans) constitute the "individual work Tasks". If for some reason a business logic class (or "bean") needs to be called from more than one Action, then it should be. I personally don't think it would be necessary for an Action to have exclusive domain over a business logic bean. It's possible that a desire to forward control from Action to Action is an indication that the business logic is too tightly coupled to the Action, and needs to be extracted into a separate object (or objects) that can called from more than one place. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/about/struts/ [EMAIL PROTECTED] wrote: > > I was pleased to read the plans for workflow processing in Struts 1.1 - > though I'm not entirely clear on what it's all about. One thing I feel is > limiting about Struts ( this surely has been voiced ) is the inability to > forward biz logic processing among various Action classes. "Action > chaining" if you will. I realize this can be accomplished messily by > forwarding from Action to Action. It sounds like the Workflow initiative > will speak to this need. > > The Workflow Processing To Do description states the goal is to: > > Create a mechanism by which business logic (now encoded in Action classes) > can be subdivided into individual work Tasks that are combined according to > configuration information (including flow control and iteration support) in > the struts-config.xml file > > Indeed this sounds like these individual work Tasks will get the 'chaining' > job done. However the workflow proposal at > http://jakarta.apache.org/struts/proposal-workflow.html didn't seem to back > up this notion as much as I was hoping (And no doubt the proposal came > first ). Rather, it demonstrates 2 example scenarios workflow processing > could be utilized, 1) a pluggable logon bean and 2) a wizard interface that > collects information over several requests. > > I didn't take away anything that specifically spoke to the subdivision of > biz logic processing among 'Tasks' or Actions. Apparently Workflow > Processing will tackle a much bigger set of goals and tasks. But will it > be in there? > > Thanks, > Craig
