MyFaces Features
Saving the full tree and model state information in the client response
Traditional JSP Applications save their state information within HttpSession
objects. This is an easy to use but poor approach:
- HttpSession objects must have an expiration date (timeout) that prevents the
server from running out of memory over the time. The always boring question
for web admins: How long should I set the session timout?
- Server restarting is a thrilling task: Will all objects in active sessions
be restored successfully? If implementation classes have changed this task
is likely to fail.
- Running multiple redundant servers is a challenge. You must use cluster
environments which are expensive and difficult to handle.
MyFaces has a different approach. It makes it possible to write sophisticated
applications without any use of the HttpSession. All state information of
the jsf tree and (optionally the model beans) is encoded to the client
response in the form of query parameters and hidden inputs in forms.
Support for saving model state
MyFaces introduces a new Component "UISaveState" with the corresponding Tag
"<myfaces_ext:save_state>".
Example (see "sample1.jsp"):
...
<jsp:useBean id="calcForm"
class="net.sourceforge.myfaces.examples.example1.CalcForm"
scope="request" />
...
<f:use_faces>
...
<x:save_state id="save1" modelReference="calcForm.number1" />
<x:save_state id="save2" modelReference="calcForm.number2" />
<x:save_state id="save3" modelReference="calcForm.result" />
...
The current values of the three properties number1, number2 and result get
automatically saved within the client response and restored from the
following client request.
You can also save the whole bean.
Example:
...
<jsp:useBean id="calcForm"
class="net.sourceforge.myfaces.examples.example1.CalcForm"
scope="request" />
...
<f:use_faces>
...
<x:save_state id="save1" modelReference="calcForm" />
...
The whole bean automatically is saved (serialized) and restored by MyFaces.
Keep in mind that to be able to save and restore the value of a bean property
or the bean itself, it must either be serializable or have a type that is
supported by a Converter (see package myfaces/converter/map).
State Saving
MyFaces supports two methods of encoding the state information:
- "Normal"
All state values are encoded as normal URL parameters.
i.e. Query parameters in HREFs and hidden inputs in FORMs
- "Zipped"
All state values are encoded to a String of key/value pairs
that is zipped (GZIP) and encoded to allowed characters (Base64).
This String is then written as one query parameter or hidden
form input.
ServletMapping
MyFaces supports two methods of mapping requests to the FacesServlet:
- Virtual path
This is Suns method that is described in the specification. All requests to
"/faces/*" are mapped to the FacesServlet.
- File extension
MyFaces offers an alternative mapping. You can map all "*.jsf" requests to
the FacesServlet. This makes linking much easier, because you can write
relative urls exactly as you would do to link to another JSP. Just replace
the extension ".jsp" by ".jsf". You could even write a HTML design prototype
in "pure" JSP and then do a search-and-replace over your JSPs to run it in
JSF.
UINavigation / NavigationRenderer (navigation and navigation_item tags)
A simple navigation component to build a vertical menu structure.
(see web\example\inc\navigation.jsp for an example)
UISortHeader / SortColumnRenderer (sortheader and sortcolumn tags)
Convenient support for writing lists, that can be (re)sorted by a click on
a column header.
(see web\example\simpleSortList.jsp for an example)
LayoutRenderer (page_layout, page_header, page_body and page_footer tags)
Support for switchable page layout.
Try the example and change the layout under "Options" to see the magic!
ListRenderer supports nested HTML and JSP
MyFaces ListRenderer does not render it's children, but rather lets child components
and embedded HTML or JSP code the chance to render. This is achieved by our magic
CallbackRenderer support.
(see list examples)