Hi, you're going to want to read this: http://java.net/jira/browse/JAVASERVERFACES-1313. As you can see
it's a non-trivial issue, but the long and short of it is that ui:include is implemented as a tag handler and
executes during the restore view phase, but isn't re-executed during invoke application. So when you use
ui:include in your backing bean code it's not present during the render response phase.
With an ajax postback any component ui:included previously will be restored, but it seems that this will
only work when partial state saving is disabled. It is possible to disable partial state saving on a per view
basis with the FULL_STATE_SAVING_VIEW_IDS context parameter. If you choose to do this you will need
to be using Mojarra 2.1 at least, and if you're going to use 2.1 you may as well use 2.1.3.
Based on my experience the acid test for using ui:include dynamically is not just to get some content to
display, say with h:outputText, but to get a UICommand to work reliably. Some of the problems I encountered
were that you'd have an h:commandButton which would not work at all (i.e. the action and actionListeners
would not execute), it would only work on the 1st click, or that it would only work on the 2nd and subsequent
However, based upon some tests I carried out yesterday I think there may be a problem using full state
saving with Richfaces 4.1.0.M1 & M2, however I had no problems with 4.0.0.Final. The initial problem I had
was that datascroller was not working when I upgraded to M1 from 4.0, but then I remembered that I had
disabled partial state saving disabled on the view. Re-enabling partial state saving got it working again. I
also noticed that with full state saving an a4j:ajax event="selectionchange" (in extendedDataTable) didn't
seem to be firing. So maybe full state saving isn't working right now in the M1/M2 releases.
I updated a JIRA https://issues.jboss.org/browse/RF-11434 yesterday with some additional information on
the suspected partial state saving issue but the RF team won't have had a chance to look at it yet, and
don't read too much into my limited testing - probably better to do your own for concrete results.
The conclusion I've now reached regarding dynamic ui:include is that whilst I did get it working, after a lot
of work, it's still causing problems so I've abandoned this approach until the Mojarra team find a solution
that works reliably with partial state saving.
Edit: apologies if my mojarra related answer is irrelevant to your myfaces specific question, it was a long
weekend, I hope you understand.
Yep, this is quite an issue.
How do you handle includes then? Full state saving is useless and very very broken. Almost nothing works with it enabled. For example an exception I got when I enabled full state saving:
So yea, we probably want to leave state saving as is since it brings more problems to the table than it solves.
But what is your workaround for include still interests me. I don't want to have bloated xhtml files floating in my app. This is one of the reasons I chose jsf2 facelet style. In theory and first concepts worked beatufully. But now stuff is starting to break down in multiple places.
Double clicking stuff probably won't make it past the testing stage.
I am in the same state as you are in. Starting with Richfaces with the idea to build a neat application but as the application started to become complex, everything started to break. The picklist, ajax event, the table and now the ui. I still have not figured out what is the alternative for ui:include. But may be I am thing to say goodbye to atleast richfaces. What about you. Have you figured out any replacement for ui
any update on this issue? I have posted on this thread
a kind of simular issue. I don't get this to work. I always need to refresh the site by hitting F5 in order to get the page rendered correctly.
I am facing the same issues and wanted to ask if there are any new findings regarding the <ui:include> problem:
I have a RichTree (RichFaces 4.0.0 Final and JSF 2.0).
By selecting a tree node, a PanelGroup should be rendered with a dynamic <ui:include src="selectedNodeTypePath" > depending on the selected TreeNode.
Due to the fact that <ui:include> is invoked before the the TreeSelectionChangeListener can change the path, I have to click the same node twice or refreshing the page with F5...
Any new ideas on this?