[thelist] Window targeting problem

Turley, Jay jayt at Meridinet.com
Mon, 17 Jan 2000 11:11:37 -0600 

[Keith Davis]:
I apologize if my earlier message was incomplete.

[Jay Turley]:
No problem. Perhaps I hadn't made it clear where my problem really lay.

[Keith]: 
Opening into the same window from a form submit is really a lot simpler
than you try to make it. The important thing is to guarantee that the
window is opened and given an HTML window hierarchy name on each submit
BEFORE the form is submitted. This cannot be accomplished with the
onsubmit method since the window.open occurs AFTER the submission has
taken place and returned a true condition. 

[Jay]:
Ahh (light bulb appears above head). In previous applications I had written,
I had always opened the windows inadvertently by choosing to maintain state
information in the query string, so I had never run into this timing
problem. In retrospect, though, it's clear that the submission is taking
place before the window is opening. I feel like a goof ;-)

[Keith]:
Follow the sequence from the onclick event, first the window is opened
and given an HTML window hierarchy name "shoppingWin", then the form is
submitted and targeted to the now existing window named "shoppingWin".
IF, shoppingWin already exits (has not been closed from prior opening)
the window.open will use the window by that name rather than create a
new window.

[Jay]: 
Yes, this is exactly what I was expecting, given the previous method I had
used to open my windows. Which is why it came as a shock to discover that by
using the post method in a form, rather than dynamically building the query
string (necessary at the time) broke my expectations for window behaviour.

[Keith]:
IMHO, if you are not doing any read/write from the
parent, don't mucky things up with the variable as it has no function.

[Jay]:
Yep. I agree, but you were viewing firsthand my increasingly frantic
attempts to kludge a solution to a problem I now realize I had created
through a unclear understanding of the timing issues involved.

[Jay]:
Thanks immeasurably for your help, Keith. I had almost given up findding an
answer, and was preparing to  rework the solution.

<tip type="JavaScript">

One of the more useful items I had to come up with was a JS method to
disable our site during a period of frequent dB maintainence. Why JS? A
number of ridiculous reasons - if you really want to know let me know;
believe me I realize this wasn't the ideal solution. In any case, I ended up
with this:

<script language="JavaScript">
	function checkTime()
	{
		var newURL = "your.sites.down.message.html";
		var today = new Date();

		// Missouri's local time zone offset is 6.
		// This will need to be customized for your
		// local time zone - check it for yourself
		// and substitute below
		var offsetMO = 6;
		var offset = today.getTimezoneOffset()/60;
		var offset = offset - offsetMO;

		// if site was to be down from 10AM-3:00PM
		var startTime = 10;
		var endTime = 15;

		var bDate = new Date("January 17, 2000 " +
(startTime+offset) + ":00");
		var eDate = new Date("January 17, 2000 " +  (endTime+offset)
+ ":00");
		if (bDate < today && today < eDate)
			document.location.replace(newURL); 
	}
</script>

<body onLoad="checkTime()">

It's not fancy, but it lets us down our site as needed. YMMV - it has no
error checking on time+offset being greater than 24 (but we have no
international clients). 

</tip>