Michael Jouravlev 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. > > > So we have two concepts: [... etc etc ] > 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.
"ah ... you speaka my language" mm. the key actions in question reside on 4 pages that contain a fair bit of data and provide the user with product-specific views of their data. so I have to be able to undertake the action and return to the same page with an update with as little screen flicker as possible (it's a mimic screen for an industrial control system - scada via www). > 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. ah, well, that's where my "stale-page trapping, multiple browser window tracing, self-inflicted framework" kicks in and solves a few problems for a change ... :) one for the boy ... > 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 :-) buring that into my neuronal ROM at present ... > Michael. Thanks again Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
