Hard to say, as we don’t know the exact question we are answering, but you could for example send a push notification via curl on a sucessful database edit, immediately after it happens.
Essentially the notification is to be shown to the user upon updating / inserting into the database.
The sockets link seemed cool but might be a bit overkill at this point as all I want to do is display a pop up notification to the user.
The key thing is - is it the user who did the update, or another user? If it’s the former, it’s dead easy, just look at the return from your query execution and decide whether to pop up the window or not. If it’s someone else, that’s when it is more difficult. Techniques to do it usually require the user who wants the notification to poll the server to look for updates.
That sounds promising. It’s definitely the former.
How would I set the notification to come up On another page after the form has been submitted?
I.e, I fill out the form on page A. Once I click submit I’m taken to page B Where I would want to see the notification.
Thanks in advance.
Fire an Ajax request every n milliseconds to check if anything has changed.
Is this really a necessary feature BTW? In my experience business people tend to have a lot less issues with a little lag in processes than we developers do. As long as it happens at some point they’re usually fine with it.
That’s how form submission normally works. You have a page with the html form code on it, and a
submit button, and an
action parameter. When the form is submitted, the PHP code specified in
action is run, and that does the insert, update or whatever, and checks whether it worked or not. It then draws a confirmation page, or an error page.
That’s pretty much standard, basic, form submission. It’s wanting to submit the form without having the screen re-draw that involves a bit more complexity with JS. Post #16 by @SamA74 covers it - check if the query worked, and draw the appropriate message.
This referred to as long polling. Web sockets is a better option. Not to mention if you do it wrong it is very easy to mess that up and end up hitting the server more frequently. You can’t just run a setInterval() with an AJAX request on a static interval. Every request has a potential of coming back in a different amount of time. So what you would need to do is recursively make that AJAX request upon receiving the the last one that was initiated. Something that can be completely avoided with web sockets.
Depends on how much time the business will allow between messages. If it is absolutely time critical then yes, use websockets. If however a delay of say up to 30 seconds is acceptable then doing an AJAX request every 30 seconds gets you updates at most 30 seconds after they happened, on average 15 seconds after they happened. Not long poll (keep connection option until there is an answer) but regular AJAX (respond immediately if something is found or not).
Websockets are nice, but harder to implement and they keep resources open at the server. Plus they are a pain to proxy and don’t work under HTTP/2 (for that you would use Server-Sent Events).
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.