Technical implementation of REST & user friendly notifications after redirects
Sometimes there is a need to show the user notifications after the redirect already on a new page.
The article describes the advantages and disadvantages of several implementations of such notifications,
There is an internal site search:
We want in cases where the result is only one immediately redirect to its page, bypassing the semi-useless list:
')
It’s just so bad to do it: what if our search found the wrong Vasya Pupkin who the user was looking for, for example, if we simply don’t have another?
Solution: on the page with Vasya's profile we will display a notification that we have only one Vasya Pupkin and on his page you are now watching:
Before we redirect the user to the page Vasya, we write to the session repository a sign that we want to show him a notification.
A rude example in PHP:
When we show Vasya's page, check the flag:
What is bad such a decision?
1. If the user starts opening many pages at the same time, then depending on the implementation, he can observe various interesting effects (small things in fact).
2. If you want to fully cache pages, problems with dependencies will not take long to wait.
The first problem can be solved in a number of ways, but in fact, the resulting intricacies of conditions and timeouts hint once more that this information does not belong to the session.
UPD: By the way, if you use cookies instead of a session, then the second problem becomes a solution. It is a pity that the first one becomes worse only :)
To get around these two problems, information about whether or not to show a notification should be passed to the URL-e.
We come to the next solution.
Everything is simple - just throw the user, say, at location / vasya /? Show_notice = 1 :
and when rendering a template, check the flag:
The real REST and only two troubles:
Another place to push notification information is the hash.
Something will turn out like:
then the user will transfer, for example, to localhost / vasya / # show_notice
Unlike the GET parameters, the server simply will not receive this information, so it’s possible to show the notification only on the client, for example, using Javascript + PrototypeJS:
Immediately after loading the localhost / vasya / # show_notice page, the address will change (without rebooting!) To localhost / vasya / # (the annoying grid cannot be removed at all, but there's nothing wrong with it again).
The article describes the advantages and disadvantages of several implementations of such notifications,
Example
There is an internal site search:
We want in cases where the result is only one immediately redirect to its page, bypassing the semi-useless list:
')
Surprised user - happy user
It’s just so bad to do it: what if our search found the wrong Vasya Pupkin who the user was looking for, for example, if we simply don’t have another?
Solution: on the page with Vasya's profile we will display a notification that we have only one Vasya Pupkin and on his page you are now watching:
Not a REST-friendly solution
Before we redirect the user to the page Vasya, we write to the session repository a sign that we want to show him a notification.
A rude example in PHP:
<?php
function doRedirect($location) {
$_SESSION['show_notice'] = true;
header("Location: $location");
}
When we show Vasya's page, check the flag:
<?php
if (@$_SESSION['show_notice']) {
... ...
}
What is bad such a decision?
1. If the user starts opening many pages at the same time, then depending on the implementation, he can observe various interesting effects (small things in fact).
2. If you want to fully cache pages, problems with dependencies will not take long to wait.
The first problem can be solved in a number of ways, but in fact, the resulting intricacies of conditions and timeouts hint once more that this information does not belong to the session.
UPD: By the way, if you use cookies instead of a session, then the second problem becomes a solution. It is a pity that the first one becomes worse only :)
To get around these two problems, information about whether or not to show a notification should be passed to the URL-e.
We come to the next solution.
GET parameter
Everything is simple - just throw the user, say, at location / vasya /? Show_notice = 1 :
<?php
function doRedirect($location) {
header("Location: $location?show_notice=1");
}
and when rendering a template, check the flag:
<?php
if (@$_GET['show_notice']) {
... ...
}
- No glitches with simultaneously opening pages.
- You can cache the pages in the forehead by URL.
The real REST and only two troubles:
- if we cache, the page will be cached twice - with a block, and without it (essentially a trifle).
- users will start giving each other links with "? show_notice = 1" - this is not very pleasant ..
document.location.hash
Another place to push notification information is the hash.
Something will turn out like:
<?php
function doRedirect($location) {
header("Location: $location#show_notice");
}
then the user will transfer, for example, to localhost / vasya / # show_notice
Unlike the GET parameters, the server simply will not receive this information, so it’s possible to show the notification only on the client, for example, using Javascript + PrototypeJS:
<div id="notice" class="notice" style="display:none"> </div>
<script type="text/javascript">
if(document.location.hash == '#show_notice')) {
$("notice").show();
document.location.hash = '';
}
</script>
Immediately after loading the localhost / vasya / # show_notice page, the address will change (without rebooting!) To localhost / vasya / # (the annoying grid cannot be removed at all, but there's nothing wrong with it again).
Source: https://habr.com/ru/post/69894/
All Articles