https://sourceforge.net/p/pexeso-php/wiki/ViewState/Recent changes to ViewStateenTue, 20 May 2014 18:10:40 -0000https://sourceforge.net/p/pexeso-php/wiki/ViewState/<div class="markdown_content"><h1 id="views-state">View's State</h1> <h2 id="introduction">Introduction</h2> <p>View's state is essential part of the framework concept. It contains actually a properties of the application at given moment of time between user's interaction. The state is changed usually by user interaction with the application. In Pexeso the state of the whole application is not that important as the state of the <a class="alink" href="/p/pexeso-php/wiki/View/">[View]</a> the user is interacting with. The state of the view then contains all the properties of the view and it's components. </p> <p>Developer of the desktop application usually consider application state as natural thing as the desktop application is stored in computer's memory all the time it runs. On the other hand application running on the server for performance and scalability reasons are either completely stateless or stores on server just very essential user informations but they can get eventually purged. </p> <p>To make development of application in Pexeso as desktop application development alike the state of the application or it's components must be kept between the user interactions. Although the PHP script processing is in it's concept stateless there are various ways how to keep informations between the script executions. The usual way is to use session feature of the PHP or PHP cache. The nature of the web application is that the user can have open different views of the application (in separate windows or tabs of the browser) or even the same view several times at once. For that reason the session nor the cache cannot be used to store application state. </p> <p>To achieve best possible user experience the state must be stored together with the concrete view the user have opened. For this reason the state is encoded in to the rendered HTML of the view so there is no limit for user on how he/she interacts with it. </p> <h2 id="states-lifecycle">State's Lifecycle</h2> <p>As the view gets through it's lifecycle stages the state gets along: </p> <ol> <li>View is initialized. <ol> <li>When view is created there is no saved state of the view so the view is in it's default state. </li> <li>If the view is updated the state is decoded from HTTP post informations, deserialized and applied to the view. </li> </ol> </li> <li>During execution stage of the view the state of the view is usually changed. These changes are captured by state manager. </li> <li>Before rendering the view the state of the view is serialized and encoded in to the rendered HTML. </li> <li>On post-back the lifecycle goes on at 1.b. </li> </ol> <h2 id="state-manager">State Manager</h2> <p>State manager is object responsible for managing state of the view. For each view there is one instance of state manager (StateManager? class) created. </p> <p>When component is added to the view during it's initialization it is also registered to the state manager using <code>registerClient()</code> method of state manager. By default state manager expects components to implement <code>px\events\IPropertyChangeNotifier</code>interface and watches for property changes of the component. Only property changes that happens after restoring state and before saving state are recorded. The component can also implement <code>px\core\IStatefull</code> interface where just watching for property changes is not suitable. For such components the property changes are not watched, instead just <code>restoreState()</code> and <code>saveState()</code> methods of the interface are called. </p></div>Jan VolfTue, 20 May 2014 18:10:40 -0000https://sourceforge.neta923fa8d10857385d961beef6aa49e184c0b0547