Actually I completely agree that business controllers and workflows belong outside of Struts. I think the problem though lies in the word workflow. Pageflow is not intended to actually do business work, but to extend the functionality of the web specific portion of the problem. As a matter of fact I have actions built to connect pageflow and Struts to WebMethods, Commons-Workflow, and BEA Weblogic Integration - all completely web agnostic business controllers. The other thing is not all applications need a full workflow tool behind struts. Architectural flexibility is what I think we need. In very complex scenarios a programmer may want to use pageflow and a workflow engine. In simple scenarios they may want to use just pageflow or just the workflow. The thing is, pageflow at it's simplist provides equivalent functionality to the current struts. Struts needs some elements of these types of functionality to become even more flexible and provide more ease of use for developers. The thing in there is significant amount of opportunity for re-use inside the web-tier alone. For example, navigation/variable handling/errors etc. can present a significant code challenge in large applications. That's why I created pageflow, to make struts easier to use for large apps. Recently, I worked on a large web app with Struts 1.1 using dynamic forms and validator and all of our business logic was in session beans. This put Struts right in it's sweet spot and it did very well, the dev team was very pleased. However, we still had quite a bit of code (14,000 lines) in action classes. Here were some of the challenges that pageflow is designed to help with: - reusable actions - a good deal of the code we wrote was the same. Take a data object from the business tier, format it for display, take the user input and pass it to the business tier. The problem was actions aren't really reusable, you have to factor out common code into utility classes which doesn't always map well. This is one place were workflow-like (Id really rather call it pageflow because of the objections you raised) saves the day. - contextual pages - if a button (like a save button) was supposed to do something different in one context over another, we had to do some pretty convoluted logic in both the actions and the jsp. With pageflow you just use a separate page-instance and connect it to a separate action. This saves immense problem around complicated page-action-page combinations. - variable handling - quite frankly it was difficult to track where form properties were assigned and how they related to scoped variables. Also, I had some junior programmers spend significant hours finding bugs in session memory handling. Pageflow provides a scopes and memory handling that makes it much easier to track down what is going where. - flexible events and filters - although not necessary, in our app we wanted to do some simple filters for a couple of page/action combos, turns out this is really hard. Also, we had a couple of instances were an event framework would have simplified our code immensely.
-----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Sunday, August 03, 2003 11:58 AM To: Struts Developers List Subject: Re: Workflow for Struts The thing I keep coming back to is whether workflows are a Struts problem. I would agree that multipage form *wizards* that collect input are definitely a Struts problem. But, I can't but help wonder whether more advanced types of workflows would be better defined as part of a business application controller -- rather than a presentation front controller, like Struts. (Or, presentation service-to-worker controller, if you are a J2EE Blueprints follower.) AFAIK, there really aren't any open-source business application controller frameworks "out there" now, and Struts often ends up filling this void. Before we talk about extending Struts so that it encroaches on business application space, perhaps we should consider whether "Struts is enough". What I'm thinking is that below Struts there should be a pure business application controller framework. It would have all the same hallmarks as Struts, such as input helpers, locations, handlers, and message resources. But, these would all have pure signatures, free of web and servlet semantics. Essentially, Struts without HTTP. While things like "wizards" would live in the Struts layer, things like "workflows" would live in this business layer. Struts could work as an extension of the business framework. Struts gathers up the input parameters, and other user gestures, and passes them to the business framework. The business framework then passes back dispatch tokens (like "success"), messages, and value objects (or collections of value objects). The business application controller decides whether to go to "success", "failure", or "outForBeer". Struts fills in the path to the web application resource representing each token. Likewise, the business application controller passed back keys to the message resources, and Struts renders the localized versions. And, of course, the business application controller passes back objects with dynamic data to display, and Struts sends them to the server pages that can render them. This is exactly what many (or even most) of us are doing now, except that we are all rolling our own proprietary solutions. I've worked with some companies that have already designed full-blown business layer frameworks such as this, based on the Struts architecture. It may be time to take the hint and develop an open source business application controller framework where we can "share the wealth" as we have done with struts. Essentially, the idea would be to take Struts and abstract-out the web and servlet semantics. Where Struts might use an Action with an ActionForward execute(ActionMapping,ActionForm,SerlvetRequest,ServletResponse), the business layer framework would use a Handler with a Location process(Dispatcher,Helper,Context) Struts then becomes a HTTP/Servlet extension of the business application controller framework. Where many developers are now writing "Actions", they could write web-semantic-free "Handlers" instead. Action classes would still be available when you really need to use web semantics, but otherwise, development effort can be put into web-free Handler classes. When web-semantics are not required, a single "gateway" Action can provide an adapter between Struts and the business layer framework. This moves most of the hard-core development completely out of Action classes and into platform-independant "POJO" classes. I think the overall Struts architecture works great for a lot of people (including me!). But when it comes to putting development effort into things like true "workflows", we want that effort to be on the business layer and outside of Struts. The need for a true business application controller is burning issue for most teams, and perhaps it's time that we addressed it head-on. We've been drifting in this direction by moving many of our utilities to the Commons, and splitting packages like the Validator in to a Commons component and a dependent Struts components. Before we think about adding anything like workflow support to the Struts core, perhaps we should declare our feelings about whether there should be a business layer framework below Struts, and whether any of us are willing to work on such a thing. Or, perhaps it is the case that the server-side of JavaServerFaces will be able to fill this role. In which case, the question becomes whether an approach to workflows will complement JSF or not. Though, personally, I would be most interested in a business application controller framework that was platform-independant and could be implemented on Java or C#, or even PHP. -Ted. --------------------------------------------------------------------- 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]
