You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@myfaces.apache.org by Apache Wiki <wi...@apache.org> on 2005/11/29 21:39:52 UTC

[Myfaces Wiki] Trivial Update of "How JSF State Management Works" by SimonKitching

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The following page has been changed by SimonKitching:
http://wiki.apache.org/myfaces/How_JSF_State_Management_Works

The comment on the change is:
Just escape MixedCase words that are not really wiki links to valid pages

------------------------------------------------------------------------------
  
  == Overview ==
  
- '''StateManager''' manages state, but you, as an end-user, have to give it
+ '''!StateManager''' manages state, but you, as an end-user, have to give it
  hints about what state needs to be kept.   That's either via
  implementing '''Serializable''' (and correct use of transient is part of
- implementing '''Serializable''') or by implementing '''StateHolder'''.
+ implementing '''Serializable''') or by implementing '''!StateHolder'''.
  
  Data is stored in two different ways in JSF: in
  scoped beans or in the component tree.  The scope of scoped beans are
@@ -23, +23 @@

  data (including entire backing beans) as part of the component tree,
  effectively making the page-scoped (or more since you can preserve
  such values across pages.   You still need to properly implement
- '''Serializable''' or '''StateHolder''' on your backing beans.
+ '''Serializable''' or '''!StateHolder''' on your backing beans.
  
  == Backtracking ==
  
- Note that '''StateManager''' is pluggable, so it's possible to implement your own alternatives to the standard state management.  Thus you could implement a strategy that allowed backtracking.
+ Note that '''!StateManager''' is pluggable, so it's possible to implement your own alternatives to the standard state management.  Thus you could implement a strategy that allowed backtracking.
  
  Another alternative to handling backtracking is to use client-side state saving and avoid the use of session-scoped data.   This also requires resyncing any other persisting backing stores (i.e. databases) when the page is reloaded.