Joe, This will be, to promote clarity, in a few parts. The first is: WHAT IS STRUTS? as you requested. (See http://rollerjm.free.fr/pro/Struts11.html#3 ).
> Elaborating from this, one might ask "what is Struts?" Then again, I don't think the answer is > critically important. I don't really care what it's called; I just > want a webapp framework that makes my job easier. Continuity with > Struts 1.x will help with that, since I won't have to live through > retraining myself and the whole team -- but we've learned to deal > with lots of change anyway. This is, I think, well-known but may need to be said at the present time. I don't see StrutsJericho as a departure from the big picture that is Struts. Struts as I see it is essentially the framework defined by the classes in Struts in part named by "Action", i.e. ActionServet, Action, ActionForm, ActionMapping, ActionForward, etc. The ActionServlet takes a client's request which has a predefined "intent" in the web.xml to employ the Struts framework (usually via ".do" in the request URL) and passes them off to the appropriate Action subclass with any predefined "hooks", such as to an ActionForm. After processing, the Action subclass passes back control with an ActionForward which tells the controller what response object to return for the client's request. The response object itself, e.g. HTML, is created by the "view helpers" in Struts, e.g. JSP pages, taglibs, etc.,, and its grabbing of data from request, page (tile), session and application scope. (This is where event based mechanism in JerichoState, which is related to but not at all essential to StrutsJericho -- controller -- comes into play.) I refer anyone interested in this to the "pretty pictures" ;-) at http://rollerjm.free.fr/pro/Struts11.html#3 which are fairly accurate, I think, and have been provided to ASF by Jean-Michel Garnier. My discussion of Struts being on the chopping block (look deeply into that chicken's eyes ;-) ) is based on seeing the controller mechanism, what Craig now calls a "monolithic" controller, being jettisoned. > Particularly > when one looks at the chain-processing model, the definition becomes > much more amorphous. I think that is 180 degrees off and that chain request processing is completely in tune with the Struts architecture for the following reasons. The controller in Struts follows what the controller is supposed to be in the classic MVC design, viz. a Strategy design pattern which has as its job "defin[ing] the way the user interface reacts to user input" (Gamma, et al, "Design Patterns: Elements of Reusable Object-Oriented Software, p. 4). The Strategy pattern essentially allows you to use different algorithms for a task. StrutsJericho clearly is an improvement on the original Struts vision in this respect in that it allows the freedom to construct different algorithms in the controller, ActionServlet, by allowing the programmer to break down the RequestProcessor into increments which can be arranged in various orders. So far as I can tell, Shale merely dumps this whole idea for a page based controller. I am not adverse to page based controllers, although I would not pursue this solution. What I am saying is that if there is a page based controller solution, it does not count as an enhancement of but rather as a destruction of Struts. If we want a framework for Java ServerPages that is enamored of a page based controller that is very cool and I would love to see it. But, even though Struts has great name recognition, grabbing the Struts name to promote a non-Struts product seems too Machievellian to me. LOL That *is* a joke, so let's laugh together. If someone can explain to me how the Struts controller vision can survive Shale, I would be very interested. If Shale is going to replace rather than enhance Struts, let's know that up front. Struts needs a big change, I think. And, I like the ideas Ted Husted has offered in StrutsJericho for Struts 2.0. Anyway, I would follow pretty much what everyone has been saying for years in terms of what is essentially Struts. Struts is pretty much the controller mechanism that defined by handing off the ball to Action subclasses and their return ActionForwards. This is a way cool idea, I think, and I would strongly suggest enhancing it rather than dumping it as the way for Struts 2.0. This does not mean I would not support any work on anything. I would support increasing rather than decreasing choices. I envision three more emails on this to the list: (1) what is JerichoState? (2) what is JerichoFaces? and (3) does Shale jettison rather than enhance Struts? Then I will put up the core of these emails with the helpful responses from the list. I hope this addressed your question about what is Struts adequately, Joe. That is the real emphasis here conbined with a note that StrutsJericho does that within the design pattern that Struts is meant, viz. the Strategy pattern aspect of the controller in the MVC pattern. JerichoState and JerichoFaces discussions to come will stress the Observer pattern of the MVC pattern and how the pluses in Java ServerFaces might be implemented in conjunction with StrutsJericho. Jack --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
