Dmitry,
Thanks for researching the issue.
The Facelets engine has a nasty 'feature' resulting in all comments
being sent to the rendered
HTML. I would try setting the following context parameter in web.xml:
<context-param>
<param-name>facelets.SKIP_COMMENTS</param-name>
<param-value>true</param-value>
</context-param>
Note that the parameter name is "javax.faces.FACELETS_SKIP_COMMENTS" in
JSF 2.0.
I wonder if it's going to solve the problem...
Calling resetStampState() should not be necessary if you are replacing
tables data set during the invoke_application
phase (in an event listener, etc.)
Regards,
Max
Dmitry Barsukov wrote:
Hi Max,
I have spent quite a bit of a time trying to localise the root of the
problem...
The outcome is not very encouraging but interesting.
This defect is quit nasty one. Fortunately it could be stripped down to 2
relatively simple forms and 2 backing beans:
1/ Main web page (simplest) and its backing been - see below
"tblbug.view.xml" & "TblBugBean.java"
2/ The simplest dialogue page and its backing bean -
see below "tblbugdialog.view.xml" & "TblBugDialog.java"
3/ faces-config.xml is omitted, there is nothing particularly fancy there.
Bug reproduction scenario:
1/ Open "tblbug.view.xml"
2/ Click on "search" - this opens a dialogue.
3/ Select "1" in the listbox
3/ Click of "select" - dialogue should close itself and the result set table
shows up.
4/ Click on "search" again- this opens a dialogue again.
5/ Select "2" in the listbox
6/ Click on "select" - dialogue closes down and the exception is being
thrown.
There are a few findings which could be important for defect resolution:
1. The defect appears only if there is a comment (<!-- blablabla -->)
within <tr:table> tag. Without comment the bug does not show up.
2. Answering your question: I am replacing the underlying data set of the
table, but I do not change the data.
3. The defect seems to be somehow linked to Trinidad dialogue framework.
When dialogue functionality is removed the defect disappears.
4. Good thing is - the simplest workaround for the bug is to using binding
and call resetStampState() function on CoreTable before replacing underling
data set.
tblbug.view.xml (stripped down to bare minimum without <f:view>, <trh:html>,
<trh:body>)
-------------------------
<tr:form id="frm_main">
<tr:commandButton id="it_search" text="search"
immediate="true" partialSubmit="true"
action="dialog:tblbugdialog"
useWindow="true"
returnListener="#{tblBugBacking.handleReturn}"/>
<tr:table id="tbl_result" value="#{tblBugBacking.resultset}"
var="row" partialTriggers=":it_search">
<!-- bla-bla-bla -->
<tr:column><tr:outputText value="#{row}"/></tr:column>
</tr:table>
</tr:form>
TblBugBean.java (mapped to tblBugBacking)
-------------------------
public class TblBugBean {
protected List resultset;
public List getResultset() {return resultset;}
public void handleReturn(ReturnEvent event) {
String result = (String) event.getReturnValue();
if (result.equals("1")) {
resultset = new ArrayList(6);
for (int i=0;i<6;i++) resultset.add("FIRST: "+i+i+i+i+i);
return;
}
if (result.equals("2")) {
resultset = new ArrayList(4);
for (int i=0;i<4;i++) resultset.add("SECOND: "+i+i+i+i+i);
}
}
}
tblbugdialog.view.xml (mapped action: dialog:tblbugdialog, stripped down to
bare minimum without <f:view>, <trh:html>, <trh:body>)
-------------------------
<tr:form>
<tr:selectOneListbox value="#{tblBugDialog.option}">
<f:selectItem itemLabel="1" itemValue="1"/>
<f:selectItem itemLabel="2" itemValue="2"/>
</tr:selectOneListbox>
<tr:commandButton id="cb_select" text="Select"
actionListener="#{tblBugDialog.done}"/>
</tr:form>
TblBugDialog.java (mapped to tblBugDialog)
-------------------------
public class TblBugDialog {
private String option;
public String getOption() {return option;}
public void setOption(String option) {this.option = option;}
public void done(ActionEvent event){
RequestContext.getCurrentInstance().returnFromDialog(option, null);
}
}
---
Sincerely yours
Dmitry Barsukov
