Christoph Thanks again for the nice reply. Here is the reason that I am looking at Struts. I am an applications programmer in a government office. Among my other (main) duties, I was assigned to be "backup" to another employee. I was shown how to restart the app, and to do some minor database manipulation. But after the other employee was escorted off the installation, the whole megilla was handed to me. While reviewing the code, I see . . .
import org.apache.log4j.Logger; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; import org.apache.struts.action.ActionMessage; import org.apache.struts.action.ActionMessages; So, it seems that this app uses struts. The app was written in 2006, so it probably is not Struts version 2. This is why I am interested in struts. This app is planned to be re-written. But the way things go around here, I will perhaps retire before that task gets done. Therefore, I am the office struts expert. Ha. Did I mention that it runs under Websphere? I suppose that when you say S2 your mean Struts version 2. This was never actually said. And concerning S2, it doesn't interest me much. I am interested in S1. I am not about to upgrade to S2 until I understand S1. All your talk about "interceptors" and "stacks" don't interest me much. What I am interested in is the application side, the Java code that gets executed. And - most important - does S1 operate like S2 as described? In your play-by-play description of the of the action (I would describe the process like this:) the Controller has disappeared. Does S2 MVC still access the "Controller"? In my understanding the Controller is split up between interceptors and action while the Model is split up between action and business logic. That implies that the MVC concept is shoe-horned into an existing, non-MVC environment. In any case, I am only interested in understanding how my ancient legacy application works. Yours Joseph Cotton On Tue, Sep 20, 2016 at 3:13 AM, Christoph Nenning < christoph.nenn...@lex-com.net> wrote: > > > > OK, the View does not send the message back to the user. Instead, the > > Controller does that. > > > > So the Controller receives the HTTP message, sends it to the Handler, > the > > Handler processes it and hands it back to the Controller. The > Controller > > passes the message to the Model, which does processing, and hands the > > message back to the Controller. The Controller passes the message to > the > > View, which processes it, and hands the message back to the Controller. > > Lastly, the Controller passes the message back to the user's browser. > > > > Is that the sequence of events? If so, then the Handler is a piece of > the > > puzzle, at least as important as the View, and instead of MVC, it should > be > > called MVHC? > > > > If you can't explain it simply, you don't understand it well enough. - > > Albert Einstein > > > > > > Hi, > > for my taste that is too theoretical. IMO it is not clear what the > Controller is in s2. > > I would describe the process like this: > - HTTP Request is passed from servlet container to s2 > - s2 invokes interceptor stack which contains s2-logic and may contain > application logic > - interceptors may decide that request is not ok (e.g. user input is > invalid or user does not have permission) and invoke a View element. In > this case the action is not invoked. > - if all interceptors are happy the action is invoked. It decides which > parts of business logic shall be run (e.g. read, update, delete data, ...) > and it decides which View element shall be executed. The action may store > data returned by business logic to be accessed by View later. > - interceptors are run again, in reverse order (it is a stack) to do > optional post-processing > - View is executed to generate response. > > There is always s2 code involved between these steps to do the actual > invokation of interceptors, action, View. > > In my understanding the Controller is split up between interceptors and > action while the Model is split up between action and business logic. > > > Regards, > Christoph > > > > > > > On Mon, Sep 19, 2016 at 9:09 PM, Dave Newton <davelnew...@gmail.com> > wrote: > > > > > On Mon, Sep 19, 2016 at 8:34 PM, Joseph B Cotton <cott...@gmail.com> > > > wrote: > > > > > > > "... and they're more or less in the right order. ..." > > > > > > > > Not really. But thank you for the nice reply. The issue here is > that my > > > > understanding is no better with your explanation. > > > > > > > > > > I think the disconnect is that you're viewing the S2 documentation > hoping > > > for an MVC tutorial, which this isn't. Entire books have been written > about > > > MVC. One part of "jargon" is serving as a common communication model. > The > > > description is presented as a description of S2, not MVC in general. > > > > > > It is curious that the introductory explanation for beginners is full > > > > of specialized and undefined jargon. > > > > > > > > > > The introductory explanation of S2 is just that; not a tutorial of > MVC, for > > > which there are better, and more extensive, tutorials. > > > > > > (As an aside, note there are multiple interpretations of what "MVC" > > > actually *is*, as most web-based MVC frameworks, especially prior to > fairly > > > recently, are quite a bit different than when the pattern was first > > > identified and implemented.) > > > > > > YMMV, but I'd rather pick specialized documentation that addresses > specific > > > concerns. > > > > > > Regarding the rewrite: it's adequate as far as it goes, but misses > some > > > fairly important points (e.g., control *is* forwarded back through the > > > controller). Think of it this way: the request is always "moving > forward" > > > through the process. But it moves "back through" the controller, > because > > > that's just how filters work. > > > > > > The view layer doesn't transmit the reply message to the user (nor is > it > > > necessarily HTML). The view layer creates the output of the request, > > > whatever that happens to be. But it isn't the view layer's > responsibility > > > to get that representation back to the user. > > > > > > The "model" (an action in S2) essentially does a data transform > between the > > > request and what is required by the view layer. The view layer does a > data > > > transform between what is given to it and what is sent back to the > client. > > > (Noting that some of this may not be written by the app developer but > can > > > be hidden within the framework, e.g., automatic JSON transformation.) > > > > > > > > > > There!!! See? No jargon. The jargon can be defined later, in the > > > > tutorial. > > > > > > > > > > I'd only reiterate that there are a large number of concepts involved > in a > > > back-end framework. IMO neither a primer nor a *framework* tutorial > are the > > > place to address those concepts directly. This is why links are > provided > > > that go in to much more detail. Other people, smarter than me, have > spent a > > > lot of energy explaining the details of the concepts that S2 > implements. I, > > > at least, would defer to their better grasp of both concept and > language, > > > and keep the S2 docs concise, and use jargon common to the field. > Again, > > > YMMV, and other S2 contributors may have different opinions--I'm > speaking > > > only for myself. > > > > > > d. > > > > > This Email was scanned by Sophos Anti Virus >
