Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.
The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/StateManagement ------------------------------------------------------------------------------ |||||||||||||||||||| Neither Advantages Or Disadvantages || || State is not tied to view || + || || || || + || + || || || || + = Client-Side Techniques = == Cookies == Pro: @@ -129, +130 @@ Additional information: * [http://www.port80software.com/support/articles/nextgenerationurls Towards Next Generation URLs] -- contains links to other notable resources, like Tim Berners Lee's [http://www.w3.org/Provider/Style/URI Cool URIs don't change] and Jakob Nielsen's [http://www.useit.com/alertbox/990321.html URL as UI]. + + == Browser objects (DOM elements, Javascript variables, Flash storage) == + Pro: + * Can store complex structures and objects. + * Depending on application requirements, state can be made relative or non-relative to page address. + + Neither: + * State and page address are not related. + + Cons: + * Lost when a page is reloaded unless special care is taken. + + Best fit: Ajax-style Single Page applications. + + How Struts can help: + * Struts does not have built-in features for saving state in client DOM/Javascript objects. + + Additional information: + * [http://codinginparadise.org/weblog/2005/08/ajax-tutorial-saving-session-across.html Saving Session Across Page Loads Without Cookies, On The Client Side] -- tutorial by Brad Neuberg == HTML form hidden fields == @@ -157, +177 @@ * Reloading a page or navigating back/forward in browser session history causes a resubmit that is preceded by a user-unfriendly POSTDATA message. * The application is unfriendly to search engines. + When to use: all application pages are based on HTML forms and storing state information in the URL is undesireble. - When to use: for an application where all pages are HTML forms and state information is not fit for storing in URL. From time to time state information should be either cleaned up or saved on server (checkpoints). - - Saving state on server at checkpoint transforms this technique from client-only to client-server. Thus, synchronization between client and server state will be required. Generally, moving back in browser session history should be prohibited after a "save-to-server" checkpoint. What to store: non-critical state information, like state of controls and widgets (viewstate). + + What to keep in mind: the moment you update the server objects or database, you switch from pure client-based technique to combined client-server tecnhique, which is a totally different beast. Many developers using hidden fields think they use client-based state tracking technique while in fact they are not. Implications: Application must provide explicit navigational links and buttons so users would not have to use standard browser navigation buttons. Application must recognize and handle double-submit situations. @@ -169, +189 @@ * Use [http://struts.apache.org/1.x/struts-taglib/tlddoc/html/hidden.html <html:hidden> tag] to store hidden field information and to submit it to location specified in <html:form> tag. * Use [http://struts.apache.org/1.2.9/api/org/apache/struts/util/TokenProcessor.html TokenProcessor class] to distinguish resubmits. + = Server-Side Techniques = - == Browser objects (DOM elements, Javascript variables, Flash storage) == - Pro: - * Can store complex structures and objects. - * Depending on application requirements, state can be made relative or non-relative to page address. - - Neither: - * State and page address are not related. - - Cons: - * Lost when a page is reloaded unless special care is taken. - - Best fit: Ajax-style Single Page applications. - - How Struts can help: - * Struts does not have built-in features for saving state in client DOM/Javascript objects. - - Additional information: - * [http://codinginparadise.org/weblog/2005/08/ajax-tutorial-saving-session-across.html Saving Session Across Page Loads Without Cookies, On The Client Side] -- tutorial by Brad Neuberg == Server session object == @@ -227, +230 @@ * EventActionDispatcher helps to structure and simplify the action code, if both input and render request phases are processed by one action. * StrutsWebIslands -- how single-page web resources (web-islands) can be implemented with Struts, no Ajax. + = Combination Client-Server Techniques = + + + === HTML form hidden fields + database === + + This is one of the more popular state management techniques. It is often used in situations where storing complete state information on server is undesired for performance reasons. Hidden fields store intermediate state during, for example, filling out a series of forms like wizard pages. One of the classic examples is web store checkout process. A series of screens ask for name, address, payment information, delivery optins, etc. The last page in the series submits the shopping cart to the server, where it is processed, the inventory is adjusted and user's credit card is charged. + + Two different states have been created: client state and server state. At this point these states are synchronized, but what happens if a user clicks Back or Reload button? A Reload button will cause resubmit of the same request, which will cause server code to charge a user's credit card and to adjust warehouse inventory one more time. + + Clicking Back button will cause browser to display checkout page with the cart, this page does not represent server state anymore, here you can see that server state and client state got out of sync. Synchonizing server to client is not possible, database update has been committed and cannot be rolled back. What is left is either synchronizing view to server (preferred choice), or throwing exception and bailing out to some safe location like welcome page. + + Pros: + * No size limitations. + * URLs are short. + + Cons: + * Every page must be an HTTP form to transfer state from page to page. + * HTTP forms must be submitted with POST method only, hidden fields are not submitted with GET. + * State is lost on redirection or on direct navigation; breaking out of a predefined page flow is not possible. + * State information grows while a user moves forward from page to page. + * Reloading a page or navigating back/forward in browser session history causes a resubmit that is preceded by a user-unfriendly POSTDATA message. + * The application is unfriendly to search engines. + + When to use: all application pages are based on HTML forms and storing state information in the URL is undesireble. + + What to store: non-critical state information, like state of controls and widgets (viewstate). + + Implications: With this technique state information is saved on server from time to time (checkpoints). Thus, synchronization between client and server state will be required. Moving back in browser session history should either be prohibited after a "save-to-server" checkpoint, or application must be able to synchronize client and server state. Application must recognize and handle double-submit situations. Application must provide explicit navigational links and buttons so users would not have to use standard browser navigation buttons. + + How Struts can help: + * Use [http://struts.apache.org/1.x/struts-taglib/tlddoc/html/hidden.html <html:hidden> tag] to store hidden field information and to submit it to location specified in <html:form> tag. + * Use [http://struts.apache.org/1.2.9/api/org/apache/struts/util/TokenProcessor.html TokenProcessor class] to distinguish resubmits. + == todo, saved for later == * Same URL can be used for several pages/forms or same URL can be used to redisplay data entry form. In most browsers this allows to reduce number of entries in page history buffer and to provide Single Page Application behavior. * If submitting a form changes server state like updating a database, then resubmitting a request can potentially produce cumulative (and wrongful) changes to server state. At this point state is handled both on client and server and its synchronization becomes problematic. - Application must be able to synchronize client and server state. + Example: a typical ASP.NET WebForms application. +
