On 1/1/10 8:09 AM, webtier_at_javadesktop.org wrote:
MA> After migrating that application to JSF 2.0.2 I experience a very
MA> different behaviour. TagHandlers now seem to be executed during the
MA> RESTORE_VIEW phase while in the JSF 1.2 version it was executed
MA> during the RENDER_RESPONSE phase. This change breaks my tags as they
MA> evaluate validation messages to provide the conditional rendering
MA> logic.
Yes, we needed to make this change to implement many of the new features
in JSF 2.0, including partial state saving, view metadata, and
bookmarkability.
MA> So I'd like to know what the current state of the facelets API
MA> is. What features from the initial facelets library are supposed to
MA> be supported in JSF 2?
Our goal with facelets in JSF 2.0 was to have 100% backwards
compatibility at the markup layer. Specifically, if the string "import
com.sun.facelets" does not appear in any of the source code of your
application, or in the source code of any of the dependencies of your
application, your facelet pages will work 100% without modification.
If "import com.sun.facelets" *does* appear in your application or
dependencies, your options all start with what I show in my blog entry,
which you have alreaady cited.
Regarding current state, we still have more work to do regarding the tag
layer of the Facelets API. We have plans to expand on what facelets
offers and give even greater control at runtime for the construction of
the UIComponent tree. Ken Paulsen and Imre Osswald have done some
excellent prototype work they are calling View Abstract Syntax Tree
(VAST) based on the best ideas from JSFTemplating and Facelets. This
work was not mature enough to include in JSF 2.0
MA> For a JSF 1.2 (with facelets 1.1.14) based application I had
MA> implemented a few "custom tags" based on the abstract
MA> com.sun.facelets.tag.TagHandler class. These tags are kind of
MA> providing conditional rendering of child content (Described in my
MA> blog at
MA>
http://www.martinahrer.at/blog/2009/10/20/control-rendering-of-ui-elements-based-on-validation-results/).
As you have discovered, this is a tricky problem. There are several
kinds of corner cases that must be considered when trying to solve this
problem. The first, and possibly most difficult, is the class of
problems that deals with modifications to the tree that would cause your
conditional values to evaluate differently between refreshes of the
component tree. Generally, we want to always have the complete tree
built, as if every condition evaluated to true, then only traverse the
parts that need to be rendered. However, this is impractical when you
have gigantic numbers of components.
You're right, we haven't figured out the most general solution yet.
MA> Is there any workaround currently available to make my tags work
MA> with some acceptable amount of required changes?
Your tag is supposed to cause a subtree to be rendered only if there are
FacesMessages on the FacesContext, right?
I recommend doing a custom component behind the tag and do the check in
its encodeBegin() method.
Others on this list may have helpful ideas too.
Ed