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 ------------------------------------------------------------------------------ || |||||||||| Client Techniques |||| Server Techniques |||| Client + Server Techniques || - || || Cookies |||| Rewritten URLs || HTML form hidden fields || Browser Objects || Session || Database || Hidden fields + session || Hidden fields + database || + || || Cookies |||| URLs || HTML form hidden fields || Browser Objects || Session || Database || Hidden fields + session || Hidden fields + database || - || || || Query parameters || Meaningful URLs || || || || || || || + || || || Query parameters || Clean URLs || || || || || || || |||||||||||||||||||| Advantages || || Can store complex data types || || || || || + || + || || || || || Works well in load balancing environments || + || + || + || + || + || || || || || @@ -109, +109 @@ }}} Pros: - * URLs simply look and may help visualize the site structure. + * URLs may help visualize the site structure. * Such URLs are more likely to be saved by search engines and crawling machines. * Manually editing URL allows to move "up" and "down" hierarchical structure of an application just like navigating directory structure on a local computer. * Underlying technology is not exposed; easier to replace a web framework, harder for hackers to get into. @@ -123, +123 @@ * State is tied to page address. Best fit: online catalogs or magazines that have hierarchical structure and should be represented as a static website. May improve site searchability and page rankings. + + 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]. == HTML form hidden fields == @@ -136, +139 @@ </form> }}} - Pro: + Pros: - * No size limitations as for query parameters. + * No size limitations. - * URLs are short + * URLs are short. - * 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. Neither: * State and page address are not directly related. Cons: - * To transfer state from page to page every page must be an HTTP form. + * 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 transferred with GET (verify this). + * 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. - * State is lost on redirection or when a user navigates to an arbitrary page. - * Breaking out of a predefined page flow is not possible. - * Generally, a user is not supposed to use standard browser navigation buttons or typing resource location in the browser address bar. - * Reloading a page or navigating back/forward in browser session history causes resubmit that is preceded by a user-unfriendly POSTDATA message. + * Reloading a page or navigating back/forward in browser session history causes a resubmit that is preceded by a user-unfriendly POSTDATA message. - * 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. + * The application is unfriendly to search engines. - When to use: you have serious reasons to offload as much state from the server as possible, your application is HTML form-based and your users are taught not to use standard browser navigation buttons when they use your application. + 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). - 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. Application must be able to synchronize client and server state. + 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. == Browser objects (DOM elements, Javascript variables, Flash storage) == Pro: @@ -206, +209 @@ Best fit: applications that treat server state as primary state source. Non-Ajax Single Page Applications. + + + == 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. +
