Stefano Mazzocchi <[EMAIL PROTECTED]> writes: > On 1 Jan 2004, at 23:25, Hunsberger, Peter wrote: > > > Upayavira <[EMAIL PROTECTED]> writes: > > > >> > >> Hunsberger, Peter wrote: > >> > >>> Any idea if it would be possible to devise a way to alter > the target > >>> frame for a response in the flow? In particular, we have > >> some search > >>> screens that show their results in different frame. If a > >> request fails > >>> validation I'd like it to return to the original frame and > >> not show the > >>> results in the other frame. So, in this case I'd just like > >> to remove > >>> the target frame if the request fails validation. > >>> > >>> Peter Hunsberger > >>> > >>> > >> I might be wrong, but I think your thinking is wrong here. > >> > >> You cannot control (from in flow) the frame that a page is > presented > >> in, because the browser does a request for a specific frame, and > >> that's where the result will be shown. > >> > >> To achieve what you want, you'd have to do it with some > client side > >> javascript. Send back a response including some javascript > that makes > >> the browser reload the other frame. > >> > >> Hope this makes sense. > > > > Yah, that makes sense, probably a little too much "grog" > last night to > > be thinking straight... I was hoping there might be some header or > > other http level setting that the browser would use to > determine what > > the target frame was for. > > Nop, there is no such thing. This is yet another of the two thousand > reasons on why you should never be using frames but you > should be doing > server side aggreation (where you *do* have full control on what > happens).
That's a bit of a pain in this particular case, not impossible, but a lot more work than just setting up the frame and calling an existing page. It's probably pretty easy to detect the error in this case and display just the error message in the second frame and that will work ok, not quite as pretty, but that's what you get for being lazy...
