Notes within: <snip> On 5/3/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
On 5/3/06, Rob Manthey <[EMAIL PROTECTED]> wrote: > > If you care about where your action is called from, > > Only so much as to have a page for the server to send back to the user - > ie: the page that they were on - not some other interim page.
</snip> I assume you are saying HTML page because that is what is displayed in the browser. However, it might be helpful to remember that what is being returned is a response. <snip>
So we have two concepts: * A certain page sends request to the server; server does stuff; then it redisplays the page where it was called from
</snip> Pages don't send anything of course. Pages are displayed and interact with the user. The server does not display a thing. I think if you start talking more accurately and more precisely you might find many of your problems will solve themselves. <snip>
* A request is sent to server from whoever it might be (aliens); server does stuff; then it selects a view according to its current state and displays it.
</snip> The request is sent to the server and the server then responds with a response. The response wraps an HTML page. The browser displays the HTML page <snip>
The second approach is simpler and is more mainstream. The first approach is more service-oriented, where an action just does some job, but does not choose a view. On the other hand, when you display a page, you need to supply data for this page, right? Unless you stashed session-scoped data somewhere, your action has to prepare output data for your page. So, it has to know what page it was called from, and this page cannot be an arbitrary page, it should be one of the pages that the action can provide data for... Um, I see what you are saying. You call an action which has to support the page you call it from... Yes, this is another way of doing things, but I would say, not very popular.
</snip> These discussions have some important facets. Actions, of course, do not "support" pages, whatever that means. Actions can be related in some fashtion to views. Thinking about exactly how this is really done is worthwhile if you are tring to build an intelligent back end. The way forms and actions are related in Struts makes some of this harder. The core to all this, in my view, is that there is a relationship between the form which precedes ActionB and which follows ActionA in the following picture: ActionA --> FORM --> ActionB. Capturing this relationship in a helpful way is a main task. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
