[Struts Wiki] Update of "StateManagement" by MichaelJouravlev

[Apache Wiki <wi...@apache.org>]

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

New page:
Work in progress!


|| - |||||| Client Techniques |||| Server Techniques ||
|| - || Cookies || HTML form hidden fields || Query parameters || Session || Database ||
|||||||||||| Advantages ||
|| Relatively easy to code || + ||   ||   || + || + ||
|| Can store complex data types ||   ||   ||   || + ||   ||
|| Works well in load balancing environments || + || + || + ||   || - ||
|||||||||||| Disadvantages ||
|| User can tamper with state information || + || + || + ||   ||   ||
|| Requires cookies || + ||   ||   || + ||   ||
|| Requires coding || + ||   ||   || + ||   ||
|| Can store only small amount of data (~2,000 bytes) ||   ||   || + ||  ||   ||
|| Increased network traffic and slightly slower response times || + || + || + ||   ||   ||
|| Requires server resources to save state information ||   ||   ||   || + || + ||
|| Application logic tightly coupled to the user interface implementation ||   || + ||   ||   ||   ||
|||||||||||| Neither Advantages Or Disadvantages ||
|| State and view not related || + ||  ||   || + ||   ||


=== Rewritten URLs ===
 * State can be preserved on redirection

=== Query parameters ===
Pro:
 * Easy to create: by submitting a form using GET method, by clicking on a link or by manually editing the resource address.
 * Reloading a page that was previously obtained with GET method does not cause POSTDATA dialog.

Neither:
 * State and page address are directly related.

Cons:
 * Can be easily damaged by a user.
 * Exposes data that is sent to the server.
 * Has limited size, usually 255 characters.
 * State is lost if a user navigates to an arbitrary page.
 * State is linked to page address, can get stale when a user navigates back on browser session history.

Best fit: stateless applications like online catalogs or magazines. A page can be reloaded without affecting the server and without warning messages. Navigating back and forward is not an issue.


=== Meaningful URLs ===
Pro:
 * Such URLs look nice and professional.
 * 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.

Neither:
 * State and page address are directly related.

Cons:
 * In addition to the same limitations as for query parameters, creating a layered URL from a browser requires either building it on client using Javascript or building it on server and then using redirect.

Best fit: stateless applications like online catalogs or magazines that have hierarchical structure and should be represented as a static website.

=== Hidden fields ===
Pro:
 * No size limitations as for query parameters.
 * 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.
 * HTTP forms must be submitted with POST method only, hidden fields are not transferred with GET (verify this).
 * 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.
 * 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.

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. 

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.

=== Cookies ===
Pro:
 * Not visible to a user
 * Can be submitted to originating server only - better security
 * Does not depend on request method (GET or POST) or how request is issued (HTML form, link, direct URL in the address bar) 
 * State is not linked to page address, can not get stale when a user navigates back on browser session history.
 * State can be preserved after browser is closed (persistent cookies).

Neither:
 * State and page address are not related.

Cons:
 * Does not work if cookies are turned off
 * Can have lifetime different from a user session, like can be saved for future sessions or can be explicitly removed during current session.
 * Can store information about a particular client, session, or application.

Best fit: non-critical user/client information usually employed for user profiling, like zip code or preferred language.

=== 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.

=== Server session object ===
Pro:
 * Can be tied to model state, not affected by browser state or current page.
 * Allows to separate the concerns, keeping state safely and securely where model resides, while treating browser as an agent providing interface with a user.
 * Developing interactive applications is greatly simplified.

Neither:
 * State and page address are not related.

Cons:
 * Session size should be carefully controlled, can affect perfomance.
 * Degrades performance in clustered system.
 * Session object can expire when browser is still open.
 * Leaving a webapp and then navigating to it again by specifying location in the address bar leads to losing state if cookies have not been enabled.

Best fit: Ajax- and non-Ajax applications that treat server state as primary, and client state is secondary. If discrepancy between view and model occurs, view is synched with the model, not vice versa.


=== Server session object + redirection after submitting an HTML form ===
Pro:
 * Clean URLs (with cookies enabled)
 * One URL can be used for one logical page or a series of pages, this makes back/forward navigation easier for a user.
 * POSTDATA dialog is now shown when a user tries to refresh a page.
 * Double submit does not occur when a user tries to refresh a page, or navigates back/forward.
 * Developing interactive applications is greatly simplified.

Cons:
 * Redirection may increase response time.
 * Can be problematic in clustered systems or with address-translating web servers since the proper redirection location cannot be obtained.

Best fit: applications that treat server state as primary state source. Non-Ajax Single Page Applications.