Assuming I have users on a page of my site.
I update this page on my server but users will not notice the difference until reloading the page.
How can a JavaScript function detect the difference and start reloading the page ?
A solution could be using a timer which reloads the page every second but this causes a lot of traffic?
The function you are asking is to have a server which can push information to the browser like Comet.
Else, you can also create an Ajax request which will test the current version of the page displayed in the browser and verify if it wasn't updated on the server side.
Once it detect that the server have a new version of the page, your script can tell it to the user (it is bad practice to reload without the user consent).
To avoid excessive call to the server, you should ensure that your Ajax request is only launch periodically (2 min ? 5 min ? More ?), and that no other request are currently running.
Related
I have a requirement where a user presses a start timer button and it begins keeping track of time. As the user moves through the website, I want the time to continue tracking, until they press the stop button.
Obviously, this cannot be achieved through client-side javascript alone, since for each page refresh time will be lost. One solution I thought was to use faye/websockets to just push the time to the browser, but for every second that lapses, that will push data to client - a strain on the server.
The only solution I can come up with is keep track of the time in javascript and then capture the page unload event send, ajax request to server with the amount of time, and let the server continue incrementing time until the next page is fully loaded. This means it will not be using push technology, just regular ajax. Is this the optimal option here or is there a better solution?
What about the case where the user kills the browser? You won't be able to capture the unload event in this case.
If you want a client side solution, try putting the start time in the localStorage where this will persist across page loads. Then when the user hits stop, you can make an ajax call to the server with the elapsed time.
I assume you need to display a timer to the user, which updates every second.
I have built a web application like that. It was a single-page application (AngularJS), so the user could navigate from 'page' to 'page' without a complete web page being loaded and the timer kept running. Would that be an option in your case?
Otherwise, you could put the start time in a cookie and every second display the difference between the current time and the start time.
A few other options, which are less preferred:
Run the web site in an iframe and keep the timer outside the iframe.
Let the timer run on the server and make a small AJAX request to the server every second (yes, I know...).
Hybrid: Let the timer run on the server and on the client and synchronize the client with the server on every page load.
Options 2 and 3 require a stateful server (with all its drawbacks).
I'm have a very long process in a php script (generate a huge pdf).
I have a button in my HTML page that launches the php script and I'd like to show a kind of progress bar or at least an animated gif and when the php script is over, display the generated pdf.
The generation of the pdf may last 15 minutes so the php engine exits in timeout and the browser too.
I there a way to declare a kind of client-side callback that would be invoked as soon as the server side process is over ?
Thanks for your replies
Edit :
Thanks for your replies :)
If I well understand, I must launch the process on server-side and "detach" my client i.e do not wait untill the process is over. Instead, my client should periodically check the progression of server-side process. Right ?
If so, I may use the following scenario :
The client sends an ajax request to the server. The server launches
the process and returns a guid to the client. This guid identifies
the job.
The client periodically checks the progression of the job
via an Ajax request, from its guid.
Once the job is over, the client can issue a last Ajax query to
download the PDF
That means that the server must save the generated PDF on its disk and wait for the final Ajax request to send the file and delete it, right ?
For something as long as 15 minutes, I wouldn't even use web sockets for this. 15 minutes is a long time and there's really no telling what the user is going to be doing in the meantime. A disconnected notification process is probably going to be more reliable in this case.
Consider something like:
User initiates process, whereby a record is stored in the database "queueing" the process to take place.
User is immediately presented with a page indicating that the process has been queued and that they can continue to use the application.
A separate application which runs periodically (every minute? every few minutes?) checks for "queued" processes in the database, updates their status to "in-progress" (so subsequent runs don't also pick up the same records), and processes them.
As each process completes, it's either removed from the database or updated to a "completed" status.
The user is otherwise notified that the process is complete.
This final notification can be done a number of ways. An email can be sent to the user, for example. Or consider a user experience similar to the Facebook notification bar. Each page in the website can check for "completed" processes when the page loads and present a "notification" in the UI which directs the user to the result of the process. If users spend a lot of time on any given page then this would be a good place to use web sockets or long polling via JavaScript to keep checking for completed processes.
The main thing is to separate the user interface from the long-running process. Web applications by design aren't suited for processes which run for that long. By separating the concerns the web application can focus just on the user interface and the command-line application can focus on the processing. (As an added bonus, this would prevent users from over-loading the server with too many concurrent processes. The command-line application can just run one record at a time, so too many concurrent processes just slows down the response, not the server.)
as #David said, but no one has covered the progress bar, the implantation of this depends on what you know ( you being the application creating the pdf ).
Do you know the size of the pdf when complete.
Do you know how long
it will take to generate.
Do you have code where you can hook into
to update the progress.
The application needs a way to know when to update the completed percentage, and by how much. If you can do that then you can either store the progress in the database with the script that crates the PDF and read it on a user facing page, or store it in a file, etc..
jQuery UI progress bar is easy to use, but you will have to know what percentage is done to be able to tell the end user.
After that it is a pretty simple matter of using ajax (jquery $.post ) and a file, that's how i do it. I just wright a simple text file with a number representing the completion percent. Load it via ajax and feed it to the jquery ui progress widget.
I am attempting to build a web page which will be viewed on a wide variety of pages. I am noticing that, although it loads quickly on my PC, it takes an uncomfortable tong time to load of other smaller devices. I would like to make a one-size-fits-all solution which will redirect the page to another url if the page load is taking too long. Here is my initial plan
add a script (to all of my pages) that sends an ajax call to the server once the page is done loading.
if the call is received within a second of the original request, do nothing.
otherwise, save a flag of some kind (to a session or the database) which triggers the redirect.
I am not sure how to put together the next part. I know that PHP can redirect via headers, but after one second, I'm assuming that the headers have already been sent. Is this even possible? I think that I have seen this behavior on other pages.
How do I check number of current visitors for my asp.net website? I am already familiar with following technique but its not close to accurate result.
Create application variable Application["UserCount"]
Increase it in session start
Decrease it in session end
This technique does not check whether the request comes from Web crawlers, robots or any other spammer servers which may request several pages in new sessions which kind of inflates the number.
I want to make sure that a person has opened up a browser (mobile or desktop) to view my website even if he is viewing other sites in same window or in different window but at least my site is open in at least one tab or one window.
Something like ajax hidden request maker that loads with each of my page and tells server that my site is open.
Thanks.
You could look at the user-agent on the request. You can use Request.Browser.Crawler to check if the request comes from a search engines crawler. It will return true if the browser is a crawler.
You could also use a javascript call to a page to update the visitor count. This could be combined with the above mentioned technique to ensure that visitor counts are only update if the request is a real user. You should also check that the request is not a crawler when you decrease the user count. For example
//increase the user count
if (Request.Browser.Crawler == false)
{
Application["user_count"] = +1;
}
//decrease the user count
if (Request.Browser.Crawler == false)
{
Application["user_count"] = -1;
}
You could also use the Session_End and Session_Start event in the application's global.asax file, to perform the same events.
You can use the Application to store the data. It's totally fine for the early stage of the website or web application. However, you may need to look into multiple access issue to the application state when the site is loaded.
My Django app displays data from a database. This data changes without user intervention, i.e. behind the scenes. Whenever it changes, I would like the webpage to update the changed sections without a full page reload.
Obviously AJAX springs to mind. When the page is loaded initially (or manually, fully re-loaded later on), the rendered template loads a JavaScript that runs window.onload = update("all"), update(...) in turn triggers a number of XMLHTTPRequests which again return data that gets transformed into HTML pieces for the corresponding sections. All works fine. At the initial page load.
Now I find myself in a Python function that saves a new object to the database.
How do I tell the browser to run update(...) ?
Do I need to somehow manually issue a request to a url that is mapped to a view which in turn renders a template that contains the JavaScript code to run update(...) ??? Oh my!
I feel like I'm not following the usual approaches.
Maybe I'm just standing to close in front of the problem.
Can anyone help me ?
2021 update: Use channels: https://channels.readthedocs.io/en/latest/
You have two choices
Have the browser poll using setTimeout()
Look into Comet -- this is a technique for pushing data from the server to the browser.
Here's an article on Comet in Django
two approaches:
just update the database and wait until the next AJAX query. That means it should do the query periodically, you'll have to balance between immediacy and server load. It helps a little if you can do a cheap query to just verify if there has been an update. Maybe make that check rely only on memcached instead of going to the DB
use comet. In short: the client does an AJAX query asking for the update. the server sees there's no update, so it doesn't answer. Instead, the connection is kept open for a long time. Eventually either the update comes and the server finally answers, or the client times out and kill the connection. In that case, the client should immediately reissue the query to keep waiting for the update.
You can also use The Websocket API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.