Yes. Instead of having a link on the left specify the right-hand frame as a target, have the link instead replace the entire frameset. To avoid needing a new frameset for each line, do the both the frameset generation and the frame content generation in the same CGI, passing the target URL in as an argument.

dws, can you give me an example of this. I have tried placing a function in as frame (FRAME SRC=$test NAME=&makerightframe)....but it doesn't seem to work. I would rather not have to generate 2 files then point to them.... what is the alternative. Thanks so much for your help. dave

Using this code for starters, I would flesh out the fragment that generates the left-hand frame, and arrange to emit URLs that look something like <a href="$ENV{'SCRIPT_NAME'}?url=$url" target=_top> You'll need to URL-encode the URL, but there's a routine in CGI.pm that will do that for you.

Then, to pass the parameters along, I'd extend the fragment that generates the frameset to add some or all of the parameters to the SRC= attributes for the frames.

I don't want to spoil your fun by providing a complete solution. Let me know if you need more.

Why is using JavaScript bad? I would think that'd be the obvious first choice.

<A href="new_right.html" target="right_frame" 
onClick="document.location.href='new_left.html'">Link</A>
[download]

With this, if you've got JS, all is well. If you don't, you still get the nav for the right frame. What's the problem with this?

-gryphon

The problem with this is graceful degradation: if Javascript is off, as Masem indicates, you could have a problem with only half of it updating. If you're willing to require Javascript, you can do both updates through it using <a href="javascript:foo()"> where foo() is a function to handle the page updates for you.

If you're not willing to require JS, and you want to change multiple frames simultaneously, then reloading the whole frameset is probably the easiest way to go. You don't have to create a separate (temp?) file for each frame, just have them pass different params to the same CGI.

It depends on your target audience which of those you want to do--also depends, I suppose, on how many other frames you're not updating at the same time.




---

If God had meant us to fly, he would *never* have give us the railroads.
    --Michael Flanders

In your above case, this *ought* to work, since one of your frames is only navigation, and assuming that all you are doing on that frame is indicating where the user is on your site, this isn't a bad use. But most people that play with frames and JS this way don't have that constant navigation frame around, and instead are updating content in both frames at the same time; with JS off, only one frame gets updated, and the other stays where it was, possibly displaying different information and confusing the user.

Certainly, if we stick to the case above, that's not a problem, but now you've got to consider how you present the navigation area: do you have an arrow pointing to the current place? If the navigation is being updated, then to be effective when JS is turned off (and you cannot ignore this situation), you need to program separate operations for a JS enabled browser (so that the navigation dynamically updates) non-JS version (simply displaying the content). While checking for JS is simple, getting that to report back to you via CGI, and then having scripts that include or disclude JS can be a pain in the butt.

It's much easier, and much more usable by all browsers, JS or not, to regenerate the frame set if you want to update two or more frames at a time, or to switch to using tables for layout (something I'm not terribly fond of, but no doubt will work in nearly all browsers today).

---

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain