Hi,
Thanks a lot for your answer, i've got more questions below so that i
can follow your advice correctly.
On 9 October 2010 00:06, Leonardo Uribe <lu4...@gmail.com> wrote:
>
> Note VariableMapper has "build time scope", or in other words, it is set
> and discarded when facelets builds the component tree. The most easy
> example is try to set some variable and then try to retrieve it on
> render response.
>
> When that "build time scope" happens? On facelets 1.1.x happens when
>
> 1. A component tree is build from facelets abstract syntax tree (AST).
> 2. A component tree is refreshed (postback before render view).
>
> At first view, the only way to make a "VariableMapper" that works on
> all events is do something similar to tomahawk t:aliasBean. On JSF 1.2 and
> JSF 1.1, this component only works fully for MyFaces but with JSF 2.0,
> now it works for Mojarra (RI). It is possible to use it on
> on 1.x and Mojarra, but with limitations (binding property assigment
> will not be wrapped).
Unfortunately, this is no go for me unless i have a way to generate
automatically backing bean on demand: in theory there can be any
number of rendering of a given layout on the same page. Using the
VariableMapper to store my temporary objects was a good workaround
until now, as this is working ok in all cases except for ajax
interactions.
> On facelets 1.1.x, when there is a postback the view is refreshed to
> addd transient components (usually html markup) and handle c:if case
> (that's a long story). It is expected existing components created
> on RestoreView phase to be only "updated", but in your case what you can
> see is the component does not change (for more information see
> com.sun.facelets.tag.jsf.ComponentHandler class method apply() ).
Well my tags are the one actually changing the component tree: i'm
generating and applying ComponentHandler instances according to custom
rules, so maybe i'm interested about the long story for the c:if case.
If this tag is allowed to change the component tree structure on an
ajax call, i was assuming that i could too, and i was not expecting
the components to hold references to the context when they were first
added to the tree. I guess i'm also a little confused because what you
are describing is a mere refresh of the view, whereas i thought ajax
was performing the whole JSF lifecycle on parts of the component tree
(and so was recreating components from scratch anyway).
As i'm a bit worried about breaking the facelets or JSF expectations
of what a tag handler is allowed to do, i'd like to know if the
ComponentHandler behaviour (trying to find existing components, not
settings their attributes again if found) is just this tag handler
contract, or if it needs to have that behaviour for other reasons that
i do not see: what's the harm in re-creating components from scratch
(or at least setting their attributes again), except performance
gained from using the cached objects?
> In theory, #{widget.label} will be evaluated on render time, but
> VariableMapper only is available on build time.
I think this is working in practice because the
UIInstructionTagHandler does re-create its associated component
instead of taking the one already in the component tree.
> My solution would be use t:aliasBean or if this is required for a component
> internally, mix t:aliasBean and the target component, so #{widget.label}
> could
> be resolved correctly.
Ok, so i'm thinking that i could make my tag tag handler create a JSF
component that will hold the values that i'm already exposing in the
VariableMapper. It could expose them again in the context in other JSF
phases after the build. I'll look into t:aliasBean to make other
components resolve their expressions by using this component.
Of course, i'll need to update the values held by this component on
ajax re-render, that's why i'd like to know if it's risky or unfit to
do so: if it's not, i will create it by hand instead of using the
standard ComponentHandler implementation.
Thanks again !
Regards,
anahide.
