Jeff,
I am not sure of the "correct" behavior. Have you tested with Sun's RI?
Paul Spencer
Jeff Bischoff wrote:
Greetings colleagues,
I have used in my web pages a pattern that apparently was not safe, yet
it worked fine with all versions of MyFaces until the current trunk
(1.1.5). Basically, when I needed to make sure a certain bean was
instantiated before using non-JSF EL, I preceded the statement with an
f:attribute like so:
<f:attribute name="Content" value="#{publicNavigation.contentPage}" />
<jsp:include page="${publicNavigation.contentPage}" />
By the time the jsp:include tag was evaluated, the publicNavigation bean
was instantiated. However, when I try with MyFaces Core 1.1.5 (built off
the trunk repeatedly over the last few weeks) this pattern fails
catastrophically. The f:attribute tag does not cause the bean to
instantiate at all! This leads to the include not being displayed on the
first request, and more severe errors if a navigation rule is processed
that navigates back to that same page.
If, however, I replace it with something like this:
<h:outputText value="#{publicNavigation.contentPage}" />
<jsp:include page="${publicNavigation.contentPage}" />
It works fine. The h:outputText forces the bean to be instantiated, and
everything renders correctly (with the addition of a superflous text
preceding it).
So why did f:attribute change to not instantiate beans anymore? What
would be a better choice of tag for this pattern? What is the safest way
to do this?
Regards,
Jeff Bischoff
Kenneth L Kurz & Associates, Inc.
