cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mats Norén <m...@alma.nu>
Subject Re: Changing response targets with flow
Date Sun, 04 Jan 2004 10:51:03 GMT
Hunsberger, Peter wrote:
> Stefano Mazzocchi <stefano@apache.org> writes:
> 
> 
>>On 1 Jan 2004, at 23:25, Hunsberger, Peter wrote:
>>
>>
>>>Upayavira <uv@upaya.co.uk> 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 
> 
> 
> 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...
> 
> 

Another approach which we´ve found quite useful is to use an iframe in a 
div with visibility set to hidden. A clientside javascript alters the 
src-attribute for the iframe which causes it to reload.
In the result from the webserver we use the onload event to call a 
callback-function which copies the content from the hidden div to the 
visible output when to frame loads.
This may not be applicable in your case but it´s another way of using 
frames. The application uses more logic on the clientside so it´s not 
for evenyone.

An introduction to inner-browsing from DevEdge:
http://devedge.netscape.com/viewsource/2003/inner-browsing/

/Mats


Mime
View raw message