OK, I'm late. This was due Thursday and today is Friday. So sue me. Aren't you supposed to save the best things for last? In any case, I'm here and I have a good tip for you, so read on.

If you do web development with Domino, you've probably fought the problem of how to get back to where you came from. What? You don't know what I'm talking about? Sure you do; let me say it more clearly:

You open a database in your browser. You're in the default view. You change to another view more appropriate to whatever it is you're doing. Because you can only see some of the documents in that view at one time, you click Next Page, Next Page, Next Page...a few times to get to where you want to be.

Then you expand one category of the view, then expand another category, then expand again to show the responses to a particular document, which is where you need to do some work. You find the document you want, open it, do whatever it is you were going to do and then save it.

This is where the problem starts.

At the end of the save you find yourself back at the top of the view. More often than not, it's not only back at the top of the view, it's at the top of the default view. If you need to do something to the document right next to the one you just left, well, you have to start the whole darn process all over again.

Switch view. Next Page. Next Page. Next Page. Expand. Expand. Expand. Finally, click, into the document you were right next to a few minutes ago.

It's frustrating. It's maddening. And, worse, it's completely unnecessary. Yeah, that's right: It doesn't have to be that way. Let me explain:

To start fixing it you first have to ask yourself, "So, what's causing this in the first place?" The problem has to do with how the application is figuring out where to send you after the save.

There are only a few ways to redirect the browser after a save. Only a few that I'm aware of, anyway. One is to use a $$Return field. I know there are people out there who use these all the time but I have had absolutely no luck making an intelligent $$Return. Maybe it's my technique, maybe you just can't do it. I don't know, but when I see an application forcing users back to the top of the wrong view after a save I immediately start looking for a $$Return field. It's usually a dead give-away.

Don't like 'em. Don't use 'em. Ever.

What I do use are WebQuerySave agents. I've talked about this in many of my sessions at Lotusphere and the Advisor events but still a lot of people don't know about it: You can use WebQuerySave agents to control the browser. Here's how:

When you run an agent in the Notes client, any Print statements...

Print "Processing document #" & i

...are sent to the status bar at the bottom of the client. It's a nice way to let users know your process hasn't died on them somewhere along the way.

That same Print statement used in a background agent sends the text directly to the Notes Log. It's a nice way to completely piss off your Notes Administrators as you fill their logs with trivial and meaningless information.

But, in a WebQuerySave agent, Print statements are written straight to the browser as HTML. One possible use of this might be to format a nice Thank You screen that picks up a few things from the document (the title, the user's name, whatever) and puts it out to the user to confirm whatever you've done. That's all well and good, but it doesn't solve the problem of getting back to where you came from in the view.

Or does it?

Actually, it does. Or, can. You see, since you can send HTML to the browser, you can also send JavaScript which, at the end of the day, is just smart HTML. With JavaScript you can do lots of different things, one of which is direct the browser to a URL. You could, for instance, do something like this:

Print "<script>"
Print "    window.location='http://www.scottgood.com';"
Print "</script>"

That little bit of JavaScript will direct the browser to go to this blog, probably not where you wanted your users to end up, but you could easily enough change it to send them where you do want them to go. The only problem is, it still doesn't solve the problem. This, really, is just as bad as the $$Return because it's going to a fixed URL--the same thing that makes the $$Return relatively useless.

So, what's a coder to do?

[A disclaimer here: There are several ways to skin the cat I'm about to skin for you. This solution is a quick, easy, fix if you're using a frameset. If you're not, there are similar techniques you can employ to end up in about the same place. I'm just not going to go into them today.]

The root of the problem here is that the URL you hope to go back to keeps changing. While you may have started at:

http://www.myserver.com/db.nsf/AllDocuments

After a little clicking around in the view you end up at a URL more like this:

http://www.myserver.com/db.nsf/AllDocuments?OpenView&Start=137&Count=200&Expand=13.3.1.2#13.3.1.2

Every click of the mouse changes the URL, so you can't possibly hard-code it into your application. What you have to do is find a way to reliably get a handle to the place you came from.

One approach is to try to use the HTTP_Referer address in your form, but that isn't reliable. When you first open a document from a view, it's good, but by the time you get into the WebQuerySave agent, it's not. By then, the form is the referrer. Also, HTTP_Referer changes if you have anything on your form that causes a refresh, like a (perish the thought) non-DHTML tabbed table or a keyword field that refreshes its values.

What you need is a reliable place from which you can consistently retrieve the last URL of the view you last left. So, what knows the URL of the view? The view does, of course. If you're using a $$ViewTemplate form (please use a $$ViewTemplate form), you can put field named Path_Info_Decoded on the form and it has, you guessed it, the URL you're currently visiting.

So, (this assumes a frameset), let's say you have a left-hand frame called "left," and main frame called "main." In the Page or Form that's loaded into the left frame, define a JavaScript variable:

<script>
    var curViewLoc;
</script>

Then, in the $$ViewTemplate, create a ComputedText area that takes the value from Path_Info_Decoded and uses it to set the value of curViewLoc in the left frame:

"<script>window.parent.left.curViewLoc=\"" + Path_Info_Decoded + "\";</script>"

Whenever the $$ViewTemplate form loads (which is whenever you click on a twistie or navigate to a new location), this function will reset the value in the left frame. However, when you open a document and navigate around in it, the value doesn't change in the left frame because there's nothing in your regular forms to change it.

Soooo....

In your WebQuerySave agent, you can write a little JavaScript in a few Print statements to retrieve and use the value of curViewLoc from the left frame as the new location to return to from the main frame:

Print "<script>"
Print "    window.location=window.parent.left.curViewLoc;"
Print "</script>"

Just as easy as that.

1. Rob McDonagh02/24/2006 07:22:03 PM
Homepage: http://www.CaptainOblivious.com

That's cool. I've seen something similar with cookies, but I think I like this better. I know all the techniques you used, of course, but I didn't put them together like that. Which is why SnTT posts rock!