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.
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
* 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.
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.
Either you stick source page name into link parameters, or you set it
on the server during previous call. But then if a user goes back using
browser's Back button, your page on a browser and your remembered page
on the server won't match. This is why sticking page name and other
related info into a link is more robust. A link by definition is
always in sync with the page it is defined in :-)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
