PDA

View Full Version : javascript page refresh

havey
May 19th, 2005, 06:47 PM
hi, i'm currently using a page refresh like so:

<script language="JavaScript"><!--
if (document.images)
else
setTimeout('location.href = location.href',1000*60*5);
//--></script>

so every 5 minutes the page refresh and does what it has to. I need to extend the useability of the page refresh to only refresh the page between (using server time) 8am-6pm Monday to Friday (and hopefully this will include the leap year)

thanks

Bill Posters
May 19th, 2005, 07:12 PM
If you have access to PHP, you can use the PHP date() (http://www.w3schools.com/php/php_date.asp) function to make things a but simpler for yourself and the browser.
You could use PHP to get the time and day of week from the server quite simply and then set it so that the refresher function is only brought into the document between 8am-6pm, Mon-Fri (server-time).
That way, you aren't adding clutter to the document during those times when you don't need to.

In the following example, I'm assuming the refresher js function has been placed into its own external js file ('refresher.js').

e.g.

<?php

$thishour = date("G");$thisday = date("w");

if ( ($thishour > 7) && ($thishour < 18) && ($thisday > 0) && ($thisday < 6) ) {
echo("<script type=\"text/javascript\" src=\"refresher.js\"></script>");
}

?>

havey
May 19th, 2005, 07:42 PM
the problem of intergrating server side code is that the page needs to be refresh for it to function in certain situations, for example - lets say the page is refreshing until friday's end time, then i would have to manually refresh the page on Monday's start time to get it going again.

Bill Posters
May 19th, 2005, 08:57 PM
Sorry, I assumed this was going to be a customer-facing page with new visitors arriving at different times of the day and week (meaning they'd be served whichever version of the page was appropriate for that time).

havey
May 19th, 2005, 09:39 PM
i'm inserting records into a database, records are available sometimes 10 per second, sometime 1 per minute, a page (locally to refresh every 5 minutes to grab and insert the data into the db baqsed on the time schedual above.

thansk

havey
May 19th, 2005, 10:41 PM
what about using the client time instead of server? ... more plausible

glenngv
May 20th, 2005, 04:01 AM
what about using the client time instead of server? ... more plausibleDon't rely on it as some user's date setting is incorrect or in a different timezone.

the problem of intergrating server side code is that the page needs to be refresh for it to function in certain situations, for example - lets say the page is refreshing until friday's end time, then i would have to manually refresh the page on Monday's start time to get it going again.
I don't understand why you said that. Of course, you need to request the page for it to start the auto-refresh. That is true even with pure javascript solution. Or do you want to update the database periodically without user intervention? :confused:

Bill Posters
May 20th, 2005, 07:17 AM
I'm still using PHP to get the server day and time, but I'm simply using it to insert the correct values into the javascript:

I've kept each portion separate, so as to keep things more clear.

e.g.

var serverHour = <?php echo date("G"); ?>;
var serverDay = <?php echo date("w"); ?>;

function checkTime() {
if ((serverDay > 0) && (serverDay < 6)
&& (serverHour > 6) && (serverHour < 19)) {
}
}

var rate = 300000; // number of milliseconds in 5 minutes
}

window.location.href = window.location.href;
}

glenngv
May 20th, 2005, 08:27 AM
I'm still using PHP to get the server day and time, but I'm simply using it to insert the correct values into the javascript:

I've kept each portion separate, so as to keep things more clear.

e.g.

var serverHour = <?php echo date("G"); ?>;
var serverDay = <?php echo date("w"); ?>;

function checkTime() {
if ((serverDay > 0) && (serverDay < 6)
&& (serverHour > 6) && (serverHour < 19)) {
}
}

var rate = 300000; // number of milliseconds in 5 minutes
}

window.location.href = window.location.href;
}

Why not just do it with pure PHP solution and dynamically output meta refresh tag based on the date and time?

Bill Posters
May 20th, 2005, 08:46 AM
The impression I get (after suggesting a comparable solution to yours) is that this is a page that has to be on-screen full-time, so needs to be able to update what's on display itself.

Once the page loads without the meta refresh (5 minutes after closing on Friday), it won't know to automatically restart the refresh process on Monday morning.
You'd still need to utilise js to ensure the browser keeps checking the time even when the meta refresh wasn't present.

glenngv
May 20th, 2005, 08:58 AM
So does it mean that the page is open 24/7 without user intervention? Why not just create a stand-alone application that periodically updates the db and run it in Windows Scheduled Task?

Bill Posters
May 20th, 2005, 09:05 AM
So does it mean that the page is open 24/7 without user intervention? Why not just create a stand-alone application that periodically updates the db and run it in Windows Scheduled Task?
Because what's been posted here already does what's required of the display page?

Is what you're suggesting really any simpler or better than what's been presented here? (honest question) …remembering that a working, browser-based solution has already been provided here and work on a stand-alone app would mean starting again by asking a fresh set of questions.

glenngv
May 20th, 2005, 09:39 AM
Your browser-based solution might work but is it efficient and safe? What if you or someone accidentally or intentionally close the browser running the page? Or what if other users access the page, so you will have 2 or more browsers recursively requesting the server! :eek: And imagine the hassle of always making the page open especially if it's just idle waiting for the next refresh.

It's not just a question of which works and the availability of the solution, it's the question of which works efficiently and safely as possible.

Bill Posters
May 20th, 2005, 10:15 AM
Your browser-based solution might work but is it efficient and safe? What if you or someone accidentally or intentionally close the browser running the page?

Then you relaunch it?
I gather the situation where it's being displayed is quite controlled, with users being aware of what the page is for and why it's open.
I'm not sure what can really go wrong beyond a user closing the browser or window.
The database doesn't stop being updated as sounds as though it's being updated by other means. This is simply a display thing.

Or what if other users access the page, so you will have 2 or more browsers recursively requesting the server! :eek:
I would hope that any server maintaining the db would be capable of supporting more than a single login user.
It's not as if users have to wait in line to be served and make their purchases when using online retail sites.
It would be a pretty pathetic server that couldn't handle two requests in the space of five minutes. It doesn't require a bucket of money to get use of a server that is capable of handling many thousands of requests every minute.
Outside working hours, the server isn't being hit at all, as the javascript isn't telling the page to refresh. The time checking is being handled client-side.

And imagine the hassle of always making the page open especially if it's just idle waiting for the next refresh.
I'm not quite getting this point.
Hassle for who (or what)?
If the page is changed, then the url of the refresher page can be stored as a favourite/bookmark/home page and redisplayed with a single click. If the browser is shut down, then it can be set to go directly to the refresher (home) page on launch.

The js solution I've posted doesn't refresh the page unless it's within working hours - during which time, it's required to refresh every five minutes, regardless of whether the db has been updated or not.

I'm not really seeing any problems, at least none that necessarily make it any less practical or safe or any more hassle than other alternatives.
Can you elaborate on what you meant?

glenngv
May 20th, 2005, 12:13 PM
Hassles...

as you said, you will relaunch the window everytime someone closes the browser.
everytime the web server shuts down for maintainance or for some reasons, you would wait for the server to go up and manually refresh the page.
if the page is run in a client workstation where a user works, it is a hassle for him to keep the page always open and do other stuff.
running a web page that uses setInterval/setTimeout after every 5 mins or so will inevitably take its toll on the client machine in the long run especially if other applications are running. You might just happen to see that the browser has crashed.

If a stand-alone app is used, it will be installed and set to run as scheduled task in the SQL server machine and not on the web server (if multi-server is setup). The app will directly access the db without going through the web server, this is nice as it off-loads the webserver. If the web server is shut down for maintenance, the app can still access the db without interruption. If the SQL server machine is shut down and restarted, the scheduler will run automatically on its next scheduled time.

So, which would you choose?

BTW, after much thought in composing this post, it came to my mind that the browser-based solution either by pure PHP or combined with Javascript, you can still automatically refresh the page on Monday if the last refresh on Friday, you still generate the meta refresh tag or javascript reload using a time delay that's equivalent to how many seconds or milliseconds there are between Friday 6PM to Monday 8AM. If my calculation is right, the hour difference between those times is approximately 80 hours. If you convert it to seconds or milliseconds, you will get hundred thousands to millions of time delay. I don't think though that it's practical to use that very long delay in setInterval or meta refresh.

Bill Posters
May 20th, 2005, 01:00 PM
Hassles...

* as you said, you will relaunch the window everytime someone closes the browser.
Would the standalone app you refer to be quittable?
If so, then I would presume that it's no harder to reopen a browser either manually or by some scheduled means than it is to reopen the standalone app.
Fwiw, browsers themselves are frequently used as 'standalone apps' in situations such as kiosks and presentation stands, so a level of durability can be assumed.

* everytime the web server shuts down for maintainance or for some reasons, you would wait for the server to go up and manually refresh the page.
Possibly an issue if the hosting has no redundancy options.
One way to avoid it would be to ensure that web server maintenance is only carried out outside of working hours. Given that the server would seem to be hosted in the same time-zone as the company, it is reasonably safe to assume that any scheduled maintenance will be carried out outside of peak usage or trading hours.
(I would imagine that a SQL servers are equally open to maintenance shutdowns, so there is always the potential for the display system to fail regardless of whether a browser-based or app-based solution is used.)
As the time checking is done client-side, the web server only really needs to be on during those periods when a refresh will be called - i.e. 8am-6pm, Mon-Fri.

* if the page is run in a client workstation where a user works, it is a hassle for him to keep the page always open and do other stuff.
They only need the page to be open for those periods when they are monitoring the updates.

* running a web page that uses setInterval/setTimeout after every 5 mins or so will inevitably take its toll on the client machine in the long run especially if other applications are running. You might just happen to see that the browser has crashed.
Browsers are far more stable than they used to be. They are often used as interactive and animated presentation environments in kiosks and other similar exhition scenarios. Presumably they wouldn't be so commonplace if they couldn't be relied upon to still be up and running after the weekend.
Afaik, there's nothing intrinsically fatalistic about the javascript I've posted.
I can't see how a modern browser would accumulate problems from that javascript.

If a stand-alone app is used, it will be installed and set to run as scheduled task in the SQL server machine and not on the web server (if multi-server is setup). The app will directly access the db without going through the web server, this is nice as it off-loads the webserver. If the web server is shut down for maintenance, the app can still access the db without interruption. If the SQL server machine is shut down and restarted, the scheduler will run automatically on its next scheduled time.
I'm not sure how all the server-side stuff actually relates to the displaying

So, which would you choose?
If I was the type of person who needed to ask for help producing what is actually relatively simple javascript, then I'd probably stick with the solution on offer now, which is presumably within my realm of understanding.

I'm sure your suggestion would provide a good solution, but there's still nothing you've forward that I feel makes it the killer option compared to the browser-based one that's already been put forward.

Still, you're clearly convinced by the idea that you suggest, so I guess you won't be mind offering the thread author a quick, completed solution - or at least, point them in the direction where they can find someone willing to produce the app for next to nothing or nothing. :)

I'm sorry if it appears that I am somehow turning this into a pi**ing contest. That surely isn't my intention. I am genuinely interested in knowing how the two options truly compare.

BTW, after much thought in composing this post, it came to my mind that the browser-based solution either by pure PHP or combined with Javascript, you can still automatically refresh the page on Monday if the last refresh on Friday, you still generate the meta refresh tag or javascript reload using a time delay that's equivalent to how many milliseconds there are between Friday 6PM to Monday 8AM.
As you say, it's not practical, but not for the reasons you think.
What happens if the browser page is changed (and returned to) or the browser is closed and reopened sometime during the weekend (for instance)?
They get the page with the 80-hour meta refresh, which means the page won't refresh itself until 80 hours from that point.
A meta refresh is relative to the time the page was last loaded. If, for some reason, the page is reloaded when it shouldn't have been, then the delay clock starts all over again. I don't believe this is an issue with the js solution posted above.

Like I say, I'm sure your suggestion would be at least as good, if not better, but given the availability of the knowledge required to produce such an application (which I presume to be more complex than producing a browser-based solution), then its potential as an achievable solution might possibly be limited.

Fwiw, neither of us really know the specifics of what is ideally needed, so it's probably best that we leave it for now until Havey comes back and possibly fills us in with enough detail for us to know what is really the best solution for him and his needs. :)

glenngv
May 20th, 2005, 01:29 PM
What happens if the browser page is changed (and returned to) or the browser is closed and reopened sometime during the weekend (for instance)?
They get the page with the 80-hour meta refresh, which means the page won't refresh itself until 80 hours from that point.
A meta refresh is relative to the time the page was last loaded. If, for some reason, the page is reloaded when it shouldn't have been, then the delay clock starts all over again. I don't believe this is an issue with the js solution posted above.

Actually, your Javascript solution will refresh to a fixed rated of 5 mins even if the user opens the page during weekends or off-work hours. That is because you hardcode the rate to 5 minutes.

But the meta refresh and javascript solution are actually the same. If the user opens the page during the weekend, the time delay generated by php should be calculated from the time the page is requested up to the appropriate time of the next refresh. Based on the time the page is requested, the php script should generated 5 mins or whatever time delay is appropriate for the next refresh. In other words, the time should be a variable (for either meta refresh or javascript solution) and not hardcoded to 5 mins.

<meta http-equiv="refresh" content="<?php echo delay ?>" />

var rate = <?php echo delay ?>;; // number of milliseconds
}

Bill Posters
May 20th, 2005, 03:00 PM
Actually, your Javascript solution will refresh to a fixed rated of 5 mins even if the user opens the page during weekends or off-work hours. That is because you hardcode the rate to 5 minutes.
I know, but that means it'll never be more than (just under) five minutes out.
An 80 hour refresh could be up to (just under) 80 hours out.

If the user opens the page during the weekend, the time delay generated by php should be calculated from the time the page is requested up to the appropriate time of the next refresh. Based on the time the page is requested, the php script should generated 5 mins or whatever time delay is appropriate for the next refresh. In other words, the time should be a variable (for either meta refresh or javascript solution) and not hardcoded to 5 mins.
I like that idea, although I'm not sure (yet) how that would perform if a weekend spanned the last day of one month or year and the beginning of the next.
Something for me to practice on to help blow off the PHP/javascript cobwebs that have accumulated since I last used either with any regularity. ;)

If nothing else, this has been an enjoyable little exercise in refamiliarising myself with js. :)

havey
May 20th, 2005, 04:50 PM
The browser app is needed so the level of durability can be assumed in the app, i'm using xml to parse an external page into an array based on a cell numbering structure i created when i parsed the ext. page. So basically i'm parsing a page for the info starting in cells 47-51 and cell 54 (i call these collection of cells a record) and then the cell number +13 the original or previous, there are 80 records at one given time. i do some fancy string manipulations and insert in sql. The sql and web server are seperate on a gig backbone. The live page serves as a display in error checking, this page actually has its own machine, with a gig nic to the database, externally this page grabbing machine uses another nic to a dial out. The information parsed get entered by many organizations and many times a day. This is what i have so far - still need to optimize it:

<%
DIM iDay
iDay = DatePart("w", Date())

SELECT CASE iDay
Case "1" strDayName = "Sunday"
Case "2" strDayName = "Monday"
Case "3" strDayName = "Tuesday"
Case "4" strDayName = "Wednesday"
Case "5" strDayName = "Thursday"
Case "6" strDayName = "Friday"
Case "7" strDayName = "Saturday"
END SELECT

aa = FormatDateTime(Time, vbShortTime) ' display 18:34

bb = "19:35" ' close time M-F Eastern
cc = "9:55" ' open time M-F Eastern

If iDay = "Friday" AND bb = "19:35" then %>
<script language="JavaScript"><!--
if (document.images)
setTimeout('location.reload(true)',1000*60*3740); /// 3740 is the number of minutes from friday's end to monday's start
else
setTimeout('location.href = location.href',1000*60*3740);
//--></script>
<% Else %>

<script language="JavaScript"><!--
if (document.images)
else
setTimeout('location.href = location.href',1000*60*1);
//--></script>

<% End If %>

// i'm worried about daylight savings - i'm trying to fathum whether i will lose records then....

Is there a better way than using an unaccessible-private web page to do this?

glenngv
May 23rd, 2005, 03:20 AM
The browser app is needed so the level of durability can be assumed in the app, i'm using xml to parse an external page into an array based on a cell numbering structure i created when i parsed the ext. page. So basically i'm parsing a page for the info starting in cells 47-51 and cell 54 (i call these collection of cells a record) and then the cell number +13 the original or previous, there are 80 records at one given time. i do some fancy string manipulations and insert in sql.
You can easily convert the ASP code for that with stand-alone vbscript app (.vbs) and let the Windows task scheduler do the periodic db update without manually coding for the scheduled time to connect to the db.

havey
Jun 7th, 2005, 07:23 AM
my problem is that i need to incorporate for the app to stand off for specific holidays, like Presidents day, and other holidays where.. if it falls on a sunday the monday is tken off, also need it to run only between certain times. Because only few holidays that actually resides on a number as a constant, like New Years Jan 1

Could this Task handler do the updates based ever changing days off.
I was gonna use a small access db to hold the date stamp of those days off and i could create tables of years. // I know there is a pattern to the calendar USA holidays, but that kind of fancy footwork is beyond my abilities

BTW - how would i schedual a task thru the schedualr..?.. would i select the dos prompt to open with a command line run c:\..\project.vbs

?)

glenngv
Jun 7th, 2005, 08:37 AM
Could this Task handler do the updates based ever changing days off.
It can't. But you could set the scheduler to run from Monday to Friday and then in your .vbs app, check holidays on the db and if current day is a holiday, do nothing and immediately exit the application.

BTW - how would i schedual a task thru the schedualr..?.. would i select the dos prompt to open with a command line run c:\..\project.vbs
?)
In the Run field of the Command Prompt dialog (Task tab), specify this:

C:\WINNT\system32\cmd.exe /c "C:\path\to\app\project.vbs"

In the Advanced Options of Schedule tab, play with the settings to come up with this schedule:

Every 5 minute(s) from 8:00 AM for 10 hour(s) every Mon, Tue, Wed, Thu, Fri of every week, starting 6/6/2005 and ending 6/6/2006

Bill Posters
Jun 7th, 2005, 09:53 AM
Fwiw, I had a brief)ish) play around with this idea using PHP back when I last posted on this thread. I worked up a solution, but not one that included 'days off' for things like public holidays.
I imagine that if there were a checkable resource - either online or manually built - which stored dates of public holidays in a format that could be read by php, then it wouldn't be too hard to factor that in another quick check that would produce a 24hr delay when a refresh occured at 8am on a public holiday.

Havey, is it really critical that the refresh isn't active during public holidays or is it just the case that refreshing at those times is pointless as no-one will be at work, so no-one will be watching/using the updated data display?

havey
Jun 9th, 2005, 05:58 AM
refreshing would be pointless, ...sry for the delay.

i've been searching and have not found an online source that provides ALL the holidays off for x amount of years in advanced. I agree, the algorythims for determining all holidays off during a year is crazy, i'm still trying to find the pattern.

found a schedual that does have holidays off, but does not display the future date: nasdaq.com/about/schedule.stm

glenngv, i understand your functions, clever

Instead of a db i think i'll just hard code the dates into the script, as i can't seen to put together a working formula for the holidays/days off, (dus to this issue: if the holiday is on a sunday the following moday is taken off)

havey
Jun 9th, 2005, 08:23 PM