Hi Joseph,
Would you like to understand the MVC architecture or to
understand the Struts 1 framework. I would recommend, you can kindly go
though the following link.
http://www.raistudies.com/struts-1/architecture-of-struts-1-mvc-framework/
http://www.roseindia.net/struts/Struts-1-Tutorial.shtml
There are many articles available on net to understand both struts and mvc
for a beginners. The documentation of struts2 may not be apt for beginners
(as you mentioned it may contains words which may not be legible for a
beginner).
My sincere apologies, if the above information is not what you are looking
for.
--
Thanks & Regards
Sreekanth Nair
On Tue, Sep 20, 2016 at 6:18 PM, Joseph B Cotton <cott...@gmail.com> wrote:
> 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
> >
>
