Hi everyone, please let me first of all express my congratulations and thank you for the remarkable effort you put into the excellent Struts framework. I also wrote a JSP/Servlet MVC framework for my organization, but I decided some time ago to abandon the effort and use Struts instead. The reason why I am writing today is because I wanted to share with you some suggestions and thoughts on the enhancement of Struts. I am very much interested in your new announcement to improve Struts regarding workflow management and handling of business logic. As I see it, a handler for processing a ServletRequest has to provide the following: 1.) Verify that the application is in the right state to carry out the incoming request. For instance, a user must be logged on or an object must have been selected before any changes on its details can be made. The applicaton state is normally represented by the objects that are located in the users HttpSession object. 2.) Process the business logic. 3.) Prepare the new application state, that is remove from or add objects to the HttpSession instance. 4.) Prepare and provide the response, that is put the necessary objects into the HttpServletResponse instance and provide the JSP. My suggestion would be to somehow anchor this separation of concerns within the Struts framework and at the same time enforce the cohesion of things that clearly should be handled together. Here are my proposals concerning the 4 Tasks listed above: 1.) Provide the possibilty to define application states. An application state would be defined by a boolean expression on the content of the HttpSession instance. Each action would have to name the valid states from where it is possible to carry out this action. Another possibiltiy would be to name the valid actions for each state you define. The framework would in either case carry out the validation. I see that Struts new feature of "transactional tokens" could be excellently included here. The states could also be used within the logic tags of the Struts Taglib. 2.) Introduce the Command pattern in this context. The action class would be extended by a factory method that creates Command objects that handle the business logic. Business logic means to me a transaction in the EJB- (or whatever) tier. If the request does not involve such a transaction, you don't have to provide such a Command object.One should only be allowed to read from the HttpSession and HttpRequest instance. 3.) The new application state will be prepared based on the action parameters and on the outcome of the business logic. This includes rendering the EJB-Tier and putting the query results into HttpSession. I think it would be a good idea to prevent people from putting things into the HttpServletRequest. 4.) Preparing the HttpServletResponse instance for the JSP that's going to be processed must take place at the same spot in the code where the name of the next JSP is being returned. I think you cannot separate that. Preparing includes rendering the EJB-Tier and putting the query results into HttpServletResponse. My first approach to this was to create on ActionForward class for each JSP, where the preparing code is within the ActionForward class, so the ActionForward class becomes reusable by different Action classes. I personally would like to see Struts moving in such a direction and would also be very happy to get involved. If anyone could comment on my thoughts it would be great. Thanks a lot. Bye Georg Opora _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
