You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Joseph B Cotton <co...@gmail.com> on 2016/09/19 20:09:59 UTC
Very confusing documentation
Can someone explain this section in the beginner's documentation
https://struts.apache.org/primer.html
?
Questions include:
What is meant by "mediated", "tied" "adapter" ? (I am a native English
speaker, with years of programming experience including Java.)
What is the difference between "represents" and "encapsulates"? These very
different terms are uses seemingly as synonyms.
"business logic and state" - again "logic" and "state" are very different
concepts. Used here as synonyms.
"Forwarded back" - oxymoron.
"Loose coupling" - oxymoron.
And, last but not least, "make applications significantly easier" - in the
category of "to boldly go" i.e. split infinitive.
Sorry to go all English teacher on you, but I really would like to
understand what the writer was intending to say. He knows what he wants to
say, but what he says is not what he intends, apparently.
In the MVC/Model 2 design pattern, application flow is mediated by a
central Controller. The Controller delegates requests - in our case, HTTP
requests - to an appropriate handler. The handlers are tied to a Model, and
each handler acts as an adapter between the request and the Model. The
Model represents, or encapsulates, an application’s business logic or
state. Control is usually then forwarded back through the Controller to the
appropriate View. The forwarding can be determined by consulting a set of
mappings, usually loaded from a database or configuration file. This
provides a loose coupling between the View and Model, which can make
applications significantly easier to create and maintain.
Re: Very confusing documentation
Posted by "Sreekanth S. Nair" <sr...@egovernments.org>.
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 <co...@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.Nenning@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 <da...@gmail.com>
> > wrote:
> > >
> > > > On Mon, Sep 19, 2016 at 8:34 PM, Joseph B Cotton <co...@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
> >
>
Re: Very confusing documentation
Posted by Dave Newton <da...@gmail.com>.
S2 is completely unlike S1 in almost every respect. S1 was EOLed some time
ago. Your best bet is to get some used books from Amazon if you need to
maintain the existing app.
Hopefully it's well-structured enough that if you go the S2 route you'll
only Haber to deal with the web-to-business logic layers.
That said, there are several other options I would also explore before
deciding on S2. A direct conversion is possible, but is essentially a
rewrite, which means there's a long-lasting direction to be decided on.
If you'd like to have a brief discussion off-list I can elaborate further.
d.
On Tuesday, September 20, 2016, Joseph B Cotton <co...@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.Nenning@lex-com.net <javascript:;>> 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 <davelnewton@gmail.com
> <javascript:;>>
> > wrote:
> > >
> > > > On Mon, Sep 19, 2016 at 8:34 PM, Joseph B Cotton <cottonj@gmail.com
> <javascript:;>>
> > > > 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
> >
>
--
e: davelnewton@gmail.com
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton <https://twitter.com/dave_newton>
b: Bucky Bits <http://buckybits.blogspot.com/>
g: davelnewton <https://github.com/davelnewton>
so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton>
Re: Very confusing documentation
Posted by Joseph B Cotton <co...@gmail.com>.
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.Nenning@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 <da...@gmail.com>
> wrote:
> >
> > > On Mon, Sep 19, 2016 at 8:34 PM, Joseph B Cotton <co...@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
>
Re: Very confusing documentation
Posted by Christoph Nenning <Ch...@lex-com.net>.
>
> 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 <da...@gmail.com>
wrote:
>
> > On Mon, Sep 19, 2016 at 8:34 PM, Joseph B Cotton <co...@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
Re: Very confusing documentation
Posted by Joseph B Cotton <co...@gmail.com>.
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
On Mon, Sep 19, 2016 at 9:09 PM, Dave Newton <da...@gmail.com> wrote:
> On Mon, Sep 19, 2016 at 8:34 PM, Joseph B Cotton <co...@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.
>
Re: Very confusing documentation
Posted by Dave Newton <da...@gmail.com>.
On Mon, Sep 19, 2016 at 8:34 PM, Joseph B Cotton <co...@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.
Re: Very confusing documentation
Posted by Joseph B Cotton <co...@gmail.com>.
"... 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.
It is curious that the introductory explanation for beginners is full
of specialized and undefined jargon.
As is usual with any new technology, one who wants to learn it must learn
the jargon. And so, I will learn the jargon.
But...
With my limited understanding of the process, I have re-written the above
paragraph, without the jargon.
There are three levels to MVC, the "Model", the "View" and the
"Controller".
An HTTP request message is received the Controller, which sends the message
to an internal handler. The handler translates the message from HTTP to a
format compatible with the Model and sends the message to the Model. The
Model applies business processes to the message, such as database read,
update and delete, and generates any appropriate reply message. The reply
message is then passed to the View module. The View module formats the
reply message into HTML for the user's browser, and transmits the reply
message to the user.
There!!! See? No jargon. The jargon can be defined later, in the
tutorial.
I hope that my explanation is "correct", not having used the MVC model.
Instead I use the three tier programming model. If the paragraph is
correct, you might consider replacing the current paragraph.
thanks
Joe
On Mon, Sep 19, 2016 at 6:55 PM, Dave Newton <da...@gmail.com> wrote:
> On Mon, Sep 19, 2016 at 4:09 PM, Joseph B Cotton <co...@gmail.com>
> wrote:
>
> > What is meant by "mediated",
>
>
> "Form a connected link between"
>
>
> > "tied"
>
>
> "Attached"
>
>
> > "adapter"
>
>
> "Connector between differing functionality"
>
>
> > ? (I am a native English
> > speaker, with years of programming experience including Java.)
> >
>
> Hm.
>
>
> > What is the difference between "represents" and "encapsulates"? These
> very
> > different terms are uses seemingly as synonyms.
> >
>
> See next.
>
>
> > "business logic and state" - again "logic" and "state" are very different
> > concepts. Used here as synonyms.
> >
>
> No, they're used as intended: either business logic *or* state *and, since
> we use "or", possible both) are represented (and encapsulated) by a model.
>
> (Noting that neither is actually mandatory in the handler, but there is *a*
> model represented by an action. It may or may not be the "final" model in a
> modeling chain.)
>
> "Forwarded back" - oxymoron.
> >
>
> Vaguely, especially if pedantry is present.
>
>
> > "Loose coupling" - oxymoron.
> >
>
> Most certainly not; "loosely coupled" is a ubiquitous term in software
> engineering.
>
> And, last but not least, "make applications significantly easier" - in the
> > category of "to boldly go" i.e. split infinitive.
> >
>
> Ah, the "split infinitive". If this were written in Latin, this would be a
> much livelier discussion. It's English, though, and even the
> heavily-prescriptive Elements of Style does not say not to split them. So
> if you are (or were) an English teacher, holding the split infinitive up as
> something that's "wrong" wouldn't hold water. It holds less water since
> this isn't an English class.
>
> He knows what he wants to say, but what he says is not what he intends,
> > apparently.
> >
>
> I'd disagree. There might be minor tweaks (when isn't there?) but the words
> used have fairly well-known meanings in both the technical and
> English-speaking community, and they're more or less in the right order.
>
> Dave
>
> --
> e: davelnewton@gmail.com
> m: 908-380-8699
> s: davelnewton_skype
> t: @dave_newton <https://twitter.com/dave_newton>
> b: Bucky Bits <http://buckybits.blogspot.com/>
> g: davelnewton <https://github.com/davelnewton>
> so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton>
>
Re: Very confusing documentation
Posted by Dave Newton <da...@gmail.com>.
On Mon, Sep 19, 2016 at 4:09 PM, Joseph B Cotton <co...@gmail.com> wrote:
> What is meant by "mediated",
"Form a connected link between"
> "tied"
"Attached"
> "adapter"
"Connector between differing functionality"
> ? (I am a native English
> speaker, with years of programming experience including Java.)
>
Hm.
> What is the difference between "represents" and "encapsulates"? These very
> different terms are uses seemingly as synonyms.
>
See next.
> "business logic and state" - again "logic" and "state" are very different
> concepts. Used here as synonyms.
>
No, they're used as intended: either business logic *or* state *and, since
we use "or", possible both) are represented (and encapsulated) by a model.
(Noting that neither is actually mandatory in the handler, but there is *a*
model represented by an action. It may or may not be the "final" model in a
modeling chain.)
"Forwarded back" - oxymoron.
>
Vaguely, especially if pedantry is present.
> "Loose coupling" - oxymoron.
>
Most certainly not; "loosely coupled" is a ubiquitous term in software
engineering.
And, last but not least, "make applications significantly easier" - in the
> category of "to boldly go" i.e. split infinitive.
>
Ah, the "split infinitive". If this were written in Latin, this would be a
much livelier discussion. It's English, though, and even the
heavily-prescriptive Elements of Style does not say not to split them. So
if you are (or were) an English teacher, holding the split infinitive up as
something that's "wrong" wouldn't hold water. It holds less water since
this isn't an English class.
He knows what he wants to say, but what he says is not what he intends,
> apparently.
>
I'd disagree. There might be minor tweaks (when isn't there?) but the words
used have fairly well-known meanings in both the technical and
English-speaking community, and they're more or less in the right order.
Dave
--
e: davelnewton@gmail.com
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton <https://twitter.com/dave_newton>
b: Bucky Bits <http://buckybits.blogspot.com/>
g: davelnewton <https://github.com/davelnewton>
so: Dave Newton <http://stackoverflow.com/users/438992/dave-newton>