2

I have been tinkering around with ui:include lately and have found it to be fairly quirky in many of its behaviors. After a some testing, it seems to me like these quirks have to do with issues go back to how ui:include fits into the jsf lifecycle. I am trying to get a better grasp on the framework, and was wondering if anyone could help me understand what is going on.

Take the following example:

index.xhtml

<h:panelGrid id="testInclude">
    <ui:include src="#{bean.pageTarget}.xhtml" />
</h:panelGrid>

bean (ManagedBean, SessionScoped)

public String getPageTarget() { return "pageA"; }
@PostConstruct
public void init() { System.out.println("new bean created"); }

pageA.xhtml

<ui:composition>
    <h:outputText value="You are on page: #{bean.pageTarget}" />
</ui:composition>

When the page is first rendered, two bean instances are created. This is directly related to there being a reference to bean in pageA. Based on one of BalusC's previous answers, this probably has to do with when ui:include is processed: dynamic ui:include with el-expression?

The curious thing is that changing bean to use CDI's conversation scope actually gets rid of this problem. Does anyone know why this works?

Community
  • 1
  • 1
Elk
  • 665
  • 1
  • 5
  • 12
  • 1
    Try the following (I haven't tested it, but if it works, I'll make it an answer): `` Expressions starting with `$` are evaluated by the Facelets engine, as is ``, whereas expressions starting with `#` are processed in the JSF lifecycle. I can offer no clues as to why `@ConversationScoped` beans differ. – Steve Jun 25 '11 at 12:57
  • Interesting! It did solve one issue I didn't mention (form elements dropping the hidden field data they use to identify themselves to the session when a ui:include is re-rendered via ajax). – Elk Jun 27 '11 at 15:02

0 Answers0