MyFaces frequently asked questions

======================================================================
1. MyFaces user FAQs

Q: One of the major advantages of the MyFaces implementation has to do with
   scalability issues, based in part on the fact that it has this feature to
   save the full state in the client. Well, Sun's EA release also has this
   context parameter called "saveStateInClient". So, what's the difference.
   Does this (new) parameter in Sun's API negate that advantage?
A:
Sun's "saveStateInClient" feature was already part of the EA2 release and was
one of the main reasons for starting this open source project, because they
implement this feature only rudimentary:
- The whole tree is serialized, base64 encoded and rendered as an hidden input
  (this is done in their UseFacesTag). Large trees result in huge parameters
  which causes heavy upstream communication (between browser and server). Some
  browsers do not even support very large parameters (IE crashes when url
  parameters are too large).
- Only form posting is supported. There is no state saving done by hyperlinks.
  (Components like our navigation would not work)
- Most of the EA examples would not work with this feature on.

Conclusion: not usable at all.

MyFaces has a different approach:
- MyFaces supports saving state in url parameters (hyperlinks).
- State saving in the client is reduced to a minimum. Only dynamical parts of a
  tree (runtime attributes, etc.) are saved in the client.
- All static information need not be saved. Components and attributes that are
  hardcoded in the JSP can be restored from there. (BTW, this is the reason why
  MyFaces needs a JSP parser)

Well, to be more "compatible", release 0.3.1 offers 4 different state saving
features:

1. "server_session"
Tree state is saved in a HTTPSession comparable to Sun's default saving with saveStateInClient = false.
This mode is for all people that can live with HTTPSessions. We are tolerant and do not want to discriminate anybody.  ;-)

2. "client_serialized"
Tree is serialized, zipped and saved as url parameter or hidden input (comparable to Sun's saving with saveStateInClient = true but additionally zips the parameter and has also support for url parameters)
This mode is mainly meant as a proof of concept.

3. "client_minimized"
Only those (dynamical) tree and component infos are saved, that could not otherwise be restored by parsing the JSP.
MyFaces' main feature as we know it. Parameters are saved in "plaintext", so convenient for debugging purposes.

4. "client_minimized_zipped"
Like "client_minimal", but additionally state info is zipped (GZIP), encoded to allowed characters (Base64) and written as one query parameter or hidden form input.
Meant for production environments, where high HTTP traffic "costs" more than zipping und unzipping. i.e. When running a fast server together with thin clients connected over Internet (and not LAN).
----------------------------------------------------------------------


======================================================================
2. Component developer FAQs


======================================================================
3. MyFaces developer FAQs

Q: Why does MyFaces include it's own JSP parser (i.e. Tomcat's "jasper")?
A:
Minimal state saving in the client instead of using servlet sessions is
a basic idea of MyFaces.
Well, to accomplish this, we use the following paradigm:
- We only save state of things (tree hierarchy, components, attributes)
that we could not restore otherwise during the next request.
Or the other way round:
- We do not put any information in hidden inputs or URL parameters, that
we could get from otherwhere when doing the "reconstitute tree".

Mind, that each browser request is independent of anything that happened
before (at least as long as we do not use servlet sessions). Now, the
main task of the "reconstitute tree" phase is to restore the component
tree to the state it had during the last "render response". Where can we
get such information? Well, most things we need to know about the tree
sits in the corresponding JSP. But, how can we get it? There is no other
way, than to parse the JSP.
Ok, we parse the JSP for our purposes. The servlet container (Tomcat)
parses the JSP again when compiling it. Sounds horrible. It is not:
MyFaces has an option (for production), that makes it cache the parsed
information for each JSP.

So, we do depend on a JSP parser. We do not (really) depend on the
jasper parser: the "jspinfo" package capsulates the parser fully. All
jasper classes where refactored to reside in the subpackage "jasper", so
there should also be no naming conflicts with the real Tomcat environment.
----------------------------------------------------------------------