Introduction
Part 1 introduces how to develop a basic photo album with Sajax, PHP and JavaScript. As we build the history stack for our application, we'll rely on client-side technology and tie it directly into the code from Part 1. This article assumes the reader has knowledge of JavaScript and browser cookies.
Save state in browser
When surfing the Internet, you are always going from one page to another, and one site to another. In this process, the web browser faithfully records the history of where you have been, creating a digital trail of breadcrumbs that can be followed step by step back to the starting point. The back button allows you to go back to where you were before your previous action, and in this sense it is the undo button of the web.
The Web is a media divided by pages. The back and forward buttons in the browser toolbar guide the browser from one page to another. When Macromedia's Flash became all the rage, developers and users discovered that Rich Internet Applications (RIAs) broke the mold. Users can browse several sites, then log into a Flash-based site and spend a few minutes on it. The game ends when the user clicks the back button. The user has not returned to the previous Flash site and has no idea where he has arrived.
The same is true for websites based entirely on Ajax - another form of RIA. Websites that allow users to interact with a page multiple times are susceptible to the back button, or any history button (for that matter). The problem with the forward and reload buttons is the same as the problem with the back button. The internal history mechanism built into web browsers is an inescapable problem. For security reasons, developers cannot tamper with the browser history or any related buttons. There is also the issue of usability. Imagine how confused the user would be if the back button suddenly popped up with a cryptic warning or the user was sent to a new website.
Build a history stack
Although the browser history cannot be changed, you can build a history for use in the RIA. Obviously, it should be somewhat separate from the browser's standard navigation tools, but as stated earlier, rich applications depart somewhat from the Web's standard page-to-page model.
We will build a stack to manage the application's historical event records, which means storing a list and adding elements at the end of the list. The stack is used to store data in last-in-first-out (LIFO) order. Although the data at the top of the stack is not deleted during rollback, this model is very close to our needs. In JavaScript, stacks can be managed using arrays.
Along with the stack is a pointer indicating our current position in the stack. When we click in the application, a new event is pushed to the top of the stack, with the pointer pointing to the last element added. When you click the application's back and forward buttons, new events are not added to the stack, but the stack's pointer is moved. Think about what happens in the history stack when you use the back button: the browser returns to the last page viewed, and the forward button that was previously unavailable suddenly becomes available. When browsing a new page, the forward button turns gray again. Elements saved later in the browser history are popped off the stack, and new events are pushed onto the top of the stack. We will reproduce this behavior in the history stack we create.
Our goal is to create a set of usable history buttons: Back, Forward, and Refresh, as shown in Figure 1.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
