Mario Ivankovits wrote:
Hi Simon!
Ok, it looks like there is simply no easy answer to making t:aliasBean
work with component binding. I've therefore added information about
this to the AliasBean.java javadoc, and to the wiki. Looks like that
is all that can be done.
Just a wild guess (didnt find the time to investigate it into every
detail):
What if we, once the view has been creates, replace alias of the
component binding with the real binding, thus we no longer need the
alias any more.
restoreView will automatically have the correct binding then.
Shouldnt this be possible?
Hmm..interesting thought.
So when the view is being *created*, we use custom code in the Tag to
ensure that the alias is set up before the child components are created.
This works around the problem of no callbacks on t:aliasBean occurring
before the children are created when t:aliasBean is inside a component
that renders its children [1].
Then in t:aliasBean.encodeEnd, walk the child components:
* getBinding("binding");
* replace all occurrences of aliasName with realName
* setBinding("binding", newBinding)
Yes, it looks like it might be possible. Needs a little tricky parsing,
though, as:
<t:aliasBean alias="#{alpha}" value="#{beta.gamma}">
<t:someComponent binding="#{alpha.delta}"/>
has to become effectively:
<t:someComponent binding="#{beta.gamma.delta}"/>
[1] It would be interesting to know whether this approach would work for
Facelets; on first view, what is the timing of binding attribute
evaluations with respect to the aliasBean's rendering methods?
Cheers,
Simon
