You're familiar with how desktop applications such as Excel, Word, Dreamweaver, and so on work. You start them up, they appear on your screen, and you do your work via documents, menu choices, dialog boxes, controls, and form fields. It can easily appear that there is no separation between the application's data processing logic and the user interface, but in fact every time you choose something from a menu, click a button, or enter something in a form field, you are actually using the user interface, and the user interface is communicating what you just did to the programming logic inside the application. The application then responds by performing its processing and providing a response to the user interface. For some actions you take there may be no visible response, whereas for others it is plain that a great deal of processing has taken place behind the scenes.
The point of this discussion is that as you provide input to the application via the user interface, you change the overall state of the application. You can think of state as the exact condition, moment to moment, of all the data and variables in the application. And the application has an obligation to take note of state changes, because it might have to respond to these changes with an action of its own (which then further changes the state of the application).
There are many things besides user interaction that can change the state of an application. For example, suppose you're playing a game and you have 15 seconds to make your move. The application will monitor the system clock and may make an action entirely independent of anything you do (except make your move) based on how many seconds have elapsed (another case of state change). What does this have to do with you? Well....
As a programmer, you may not think much about state when programming desktop applications, because you're used to seamless communications between your user interface and your programming logic. But programming for the Web forces you to address the issue, because HTTP communications are stateless. HTTP is a stateless protocol because there is no built-in mechanism that tracks the state of every object in the user interface and informs the programming logic of it, or vice versa.
Instead, communications between browser and server take the form of clicks on links or form submissions. Not only is this driven by the user (instead of being automatic), but for folks with slower connections or intermittent connections it can be slow and time-consuming. So building an online application with PHP requires you to use other mechanisms for maintaining state, and you need to take measures to cope with the fact that the user interface is disconnected and may not respond at all in the way you would ordinarily expect.
|copyright © dedserveronline.com|