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 ------------------------------------------------------------------------------ || Works well in load balancing environments || + || + || + || + || + || || || || || || Works well in Ajax applications || + || || || || + || + || || || || |||||||||||||||||||| Disadvantages || - || User can tamper with state information || + || + || + || + || || || || || || + || User can tamper with state information || || + || + || + || || || || || || || Requires cookies || + || || || || || + || || || || || Requires coding || + || || || || + || + || || || || + || Requires redirection || || || + || || || || || || || + || Requires Javascript || || || + || || + || || || || || || 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 || || || || + || || || || || || + || Does not work well with redirection || || || || + || + || || || || || || State can be lost on page reload || || || || || + || || || || || || State can be lost on direct navigation || || + || || + || + || || || || || |||||||||||||||||||| Neither Advantages Or Disadvantages || @@ -30, +33 @@ * 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). + * Can have lifetime different from a user session; can be preserved after browser is closed (persistent cookies) or can be removed during user session. Neither: * State and page address are not related. Cons: - * Does not work if cookies are turned off + * Does not work if cookies are turned off in a browser. + * May be percieved as potential privacy concern. - * 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. + Best fit: non-critical information about a particular client, session, or application. Usually employed for user profiling, like zip code or preferred language. Also used for "remember me" login. == Rewritten URLs == + === Query parameters === - By year, vehicle, make: + URL ''query parameters'' allow to express a website structure using base path to a resource, in case of Struts that would be an action, and series of query parameters + + For example, an online tire store may expose its structure like this: {{{ - www.tirestore.com/selectVehicle.do?yr=2002&mk=TOYOTA&model=mr2spyder + www.tirestore.com/vehicle.do?year=2002&make=TOYOTA&model=mr2spyder + }}} + + A series of HTML forms may help a user to get to desired location, making the address more detailed from step to step: + {{{ + Welcome page allows to select search criteria: + www.tirestore.com/welcome.do + + We choose to search product by vehicle year and make: + www.tirestore.com/vehicle.do?year=2002&make=TOYOTA + + Then application shows a listbox with applicable model names and allows to select one: + www.tirestore.com/vehicle.do?year=2002&make=TOYOTA&model=mr2spyder }}} 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. + * Has limited size, usually about 2000 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. + Neither: + * State is tied to page address. + - 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. + Best fit: applications where the query string only affects the view, like online catalogs or magazines. A page can be reloaded without affecting the server and without POSTDATA messages. Navigating back and forward is not an issue. - === Meaningful URLs === + === Clean URLs === - By year, vehicle, make: + ''Clean URLs'' or ''cool URLs'' is a way to express website structure using location path instead of query parameters. Clean URLs work best for static websites. Representing state with clean URLs is less common. It is not convenient either, especially when location is being built as a result of an HTML form submission. + + For example, an online tire store may expose its structure like this: {{{ www.tirestore.com/vehicle/2002/toyota/mr2spyder/ }}} + A series of HTML forms may help a user to get to desired location, making the address more detailed from step to step: + {{{ + Welcome page allows to select search criteria: + www.tirestore.com/welcome + We choose to search product by vehicle year and make: + www.tirestore.com/vehicle/2002/toyota/ + + Then application shows a listbox with applicable model names and allows to select one: + www.tirestore.com/vehicle/2002/toyota/mr2spyder/ + }}} + - Pro: + Pros: - * Such URLs look nice and professional. + * URLs simply look and 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. + * 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. - Neither: - * State and page address are directly related. - Cons: + * Can be easily damaged by a user. + * Has limited size, usually about 2000 characters. - * 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. + * Creating a clean URL from a browser requires either building it on client using Javascript or building it on server and then using redirect. + Neither: + * State is tied to page address. + - Best fit: stateless applications like online catalogs or magazines that have hierarchical structure and should be represented as a static website. + 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. == HTML form hidden fields ==
