Sorry I keep uploading the same message, having some problems with my email:-) Anyway, I downloaded Tomcat 4.1.27 and deployed the war file and it worked ok. Maybe you need to delete you work directory so that it loads the new files. I had some trouble with that initially.
-----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]
