[ICE-7185] ice:dataTable getters called for unrendered panelTabs - ICEsoft JIRA Issue Tracker

Tyler Johnson created issue - 05/Sep/11 5:26 AM

Tyler Johnson made changes - 05/Sep/11 5:30 AM

Field	Original Value	New Value
Salesforce Case		[5007000000I1Ht3]
Description	Consider the following source code: @SessionScoped public class A implements Serializable { @PostConstruct public void init() { System.out.println("A Created "); } public List<String> getA() { return Arrays.asList("A", "A"); } } and a second bean: @SessionScoped public class B implements Serializable { @PostConstruct public void init() { System.out.println("B Created "); } public List<String> getB() { return Arrays.asList("B", "B"); } } and finally the view: <h:form> <ice:panelTabSet> <ice:panelTab label="1"> </ice:panelTab> <ice:panelTab label="2"> <h:dataTable value="#{b}" var="_b"> <h:column> <ice:outputText value="#{_b}"/> </h:column> </h:dataTable> </ice:panelTab> <ice:panelTab label="3"> <h:dataTable value="#{a}" var="_a"> <h:column> <ice:outputText value="#{_a}"/> </h:column> </h:dataTable> </ice:panelTab> </ice:panelTabSet> </h:form> If you navigate to tab 2, the first bean´s init method will be called ("B Created"). Then navigate to tab 3 and you will see the same for A ("A created"). If you swap out the h:dataTable/h:column and replace it with it´s ice equivalents and retry the above test, both B and A are created at the same time when you click on tab 2 (("B Created" & "A Created"). Having all getters called can hurt performance since they may contain expensive logic such as DB accesses, etc..	Consider the following source code: @SessionScoped public class A implements Serializable{ @PostConstruct public void init(){ System.out.println("A Created "); } public List<String> getA(){ return Arrays.asList("A", "A"); } } and a second bean: @SessionScoped public class B implements Serializable{ @PostConstruct public void init(){ System.out.println("B Created "); } public List<String> getB(){ return Arrays.asList("B", "B"); } } and finally the view: <h:form> <ice:panelTabSet> <ice:panelTab label="1"> </ice:panelTab> <ice:panelTab label="2"> <h:dataTable value="#{b}" var="_b"> <h:column> <ice:outputText value="#{_b}"/> </h:column> </h:dataTable> </ice:panelTab> <ice:panelTab label="3"> <h:dataTable value="#{a}" var="_a"> <h:column> <ice:outputText value="#{_a}"/> </h:column> </h:dataTable> </ice:panelTab> </ice:panelTabSet> </h:form> If you navigate to tab 2, the first bean´s init method will be called ("B Created"). Then navigate to tab 3 and you will see the same for A ("A created"). If you swap out the h:dataTable/h:column and replace it with it´s ice equivalents and retry the above test, both B and A are created at the same time when you click on tab 2 (("B Created" & "A Created"). Having all getters called can hurt performance since they may contain expensive logic such as DB accesses, etc..

Tyler Johnson made changes - 05/Sep/11 5:38 AM

Description

Consider the following source code:

@SessionScoped
public class A implements Serializable{
       @PostConstruct
       public void init(){
System.out.println("A Created ");
}

public List<String> getA(){
return Arrays.asList("A", "A");
}
}

and a second bean:

@SessionScoped
public class B implements Serializable{
@PostConstruct
public void init(){
System.out.println("B Created ");
}

public List<String> getB(){
return Arrays.asList("B", "B");
}
}

and finally the view:

    <h:form>
<ice:panelTabSet>
<ice:panelTab label="1">
</ice:panelTab>
<ice:panelTab label="2">
<h:dataTable value="#{b}" var="_b">
<h:column>
<ice:outputText value="#{_b}"/>
</h:column>
</h:dataTable>
</ice:panelTab>
<ice:panelTab label="3">
<h:dataTable value="#{a}" var="_a">
<h:column>
<ice:outputText value="#{_a}"/>
</h:column>
</h:dataTable>
</ice:panelTab>
</ice:panelTabSet>
</h:form>

If you navigate to tab 2, the first bean´s init method will be called ("B Created"). Then navigate to tab 3 and you will see the same for A ("A created"). If you swap out the h:dataTable/h:column and replace it with it´s ice equivalents and retry the above test, both B and A are created at the same time when you click on tab 2 (("B Created" & "A Created"). Having all getters called can hurt performance since they may contain expensive logic such as DB accesses, etc..

Consider the following source code (BeanA and BeanB source is the same):

@ManagedBean
@SessionScoped
public class BeanA implements Serializable
{

private List<String> a;

@PostConstruct
public void init(){
Thread.dumpStack();
System.out.println("A Created ");
}

public List<String> getA(){
return Arrays.asList("A", "A");
}

public void setA(List<String> b) {
a = a;
}
}

and finally the view:

<h:form>
<ice:panelTabSet>
<ice:panelTab label="1">
</ice:panelTab>
<ice:panelTab label="2">
<ice:dataTable value="#{beanB.b}" var="_b">
<ice:column>
<ice:outputText value="#{_b}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
<ice:panelTab label="3">
<ice:dataTable value="#{beanA.a}" var="_a">
<ice:column>
<ice:outputText value="#{_a}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
</ice:panelTabSet>
</h:form>

If you navigate to tab 2, the first bean´s init method will be called ("B Created"). Then navigate to tab 3 and you will see the same for A ("A created"). If you swap out the h:dataTable/h:column and replace it with it´s ice equivalents and retry the above test, both B and A are created at the same time when you click on tab 2 (("B Created" & "A Created"). Having all getters called can hurt performance since they may contain expensive logic such as DB accesses, etc..

Tyler Johnson made changes - 05/Sep/11 5:43 AM

Attachment

sc10442.war [ 13491 ]

Tyler Johnson made changes - 05/Sep/11 7:13 AM

Description

Consider the following source code (BeanA and BeanB source is the same):

@ManagedBean
@SessionScoped
public class BeanA implements Serializable
{

private List<String> a;

@PostConstruct
public void init(){
Thread.dumpStack();
System.out.println("A Created ");
}

public List<String> getA(){
return Arrays.asList("A", "A");
}

public void setA(List<String> b) {
a = a;
}
}

and finally the view:

<h:form>
<ice:panelTabSet>
<ice:panelTab label="1">
</ice:panelTab>
<ice:panelTab label="2">
<ice:dataTable value="#{beanB.b}" var="_b">
<ice:column>
<ice:outputText value="#{_b}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
<ice:panelTab label="3">
<ice:dataTable value="#{beanA.a}" var="_a">
<ice:column>
<ice:outputText value="#{_a}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
</ice:panelTabSet>
</h:form>

If you navigate to tab 2, the first bean´s init method will be called ("B Created"). Then navigate to tab 3 and you will see the same for A ("A created"). If you swap out the h:dataTable/h:column and replace it with it´s ice equivalents and retry the above test, both B and A are created at the same time when you click on tab 2 (("B Created" & "A Created"). Having all getters called can hurt performance since they may contain expensive logic such as DB accesses, etc..

Consider the following source code (BeanA and BeanB source is the same):

@ManagedBean
@SessionScoped
public class BeanA implements Serializable
{
private List<String> a;

@PostConstruct
public void init(){
Thread.dumpStack();
System.out.println("A Created ");
}

public List<String> getA(){
return Arrays.asList("A", "A");
}

public void setA(List<String> b) {
a = a;
}
}

and finally the view:

<h:form>
<ice:panelTabSet>
<ice:panelTab label="1">
</ice:panelTab>
<ice:panelTab label="2">
<ice:dataTable value="#{beanB.b}" var="_b">
<ice:column>
<ice:outputText value="#{_b}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
<ice:panelTab label="3">
<ice:dataTable value="#{beanA.a}" var="_a">
<ice:column>
<ice:outputText value="#{_a}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
</ice:panelTabSet>
</h:form>

If you navigate to tab 2, the first bean´s init method will be called ("B Created"). Then navigate to tab 3 and you will see the same for A ("A created"). If you swap out the h:dataTable/h:column and replace it with it´s ice equivalents and retry the above test, both B and A are created at the same time when you click on tab 2 (("B Created" & "A Created"). Having all getters called can hurt performance since they may contain expensive logic such as DB accesses, etc..

Tyler Johnson made changes - 05/Sep/11 7:14 AM

Description

Consider the following source code (BeanA and BeanB source is the same):

@ManagedBean
@SessionScoped
public class BeanA implements Serializable
{
private List<String> a;

@PostConstruct
public void init(){
Thread.dumpStack();
System.out.println("A Created ");
}

public List<String> getA(){
return Arrays.asList("A", "A");
}

public void setA(List<String> b) {
a = a;
}
}

and finally the view:

<h:form>
<ice:panelTabSet>
<ice:panelTab label="1">
</ice:panelTab>
<ice:panelTab label="2">
<ice:dataTable value="#{beanB.b}" var="_b">
<ice:column>
<ice:outputText value="#{_b}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
<ice:panelTab label="3">
<ice:dataTable value="#{beanA.a}" var="_a">
<ice:column>
<ice:outputText value="#{_a}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
</ice:panelTabSet>
</h:form>

If you navigate to tab 2, the first bean´s init method will be called ("B Created"). Then navigate to tab 3 and you will see the same for A ("A created"). If you swap out the h:dataTable/h:column and replace it with it´s ice equivalents and retry the above test, both B and A are created at the same time when you click on tab 2 (("B Created" & "A Created"). Having all getters called can hurt performance since they may contain expensive logic such as DB accesses, etc..

Consider the following source code (BeanA and BeanB source is the same):

@SessionScoped
public class BeanA implements Serializable
{
@PostConstruct
public void init(){
System.out.println("A Created ");
}

public List<String> getA(){
return Arrays.asList("A", "A");
}
}

and the view:

<h:form>
<ice:panelTabSet>
<ice:panelTab label="1">
</ice:panelTab>
<ice:panelTab label="2">
<ice:dataTable value="#{beanB.b}" var="_b">
<ice:column>
<ice:outputText value="#{_b}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
<ice:panelTab label="3">
<ice:dataTable value="#{beanA.a}" var="_a">
<ice:column>
<ice:outputText value="#{_a}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
</ice:panelTabSet>
</h:form>

If you navigate to tab 2, the first bean´s init method will be called ("B Created"). Then navigate to tab 3 and you will see the same for A ("A created"). If you swap out the h:dataTable/h:column and replace it with it´s ice equivalents and retry the above test, both B and A are created at the same time when you click on tab 2 (("B Created" & "A Created"). Having all getters called can hurt performance since they may contain expensive logic such as DB accesses, etc..

Tyler Johnson made changes - 05/Sep/11 7:15 AM

Description

Consider the following source code (BeanA and BeanB source is the same):

@SessionScoped
public class BeanA implements Serializable
{
@PostConstruct
public void init(){
System.out.println("A Created ");
}

public List<String> getA(){
return Arrays.asList("A", "A");
}
}

and the view:

<h:form>
<ice:panelTabSet>
<ice:panelTab label="1">
</ice:panelTab>
<ice:panelTab label="2">
<ice:dataTable value="#{beanB.b}" var="_b">
<ice:column>
<ice:outputText value="#{_b}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
<ice:panelTab label="3">
<ice:dataTable value="#{beanA.a}" var="_a">
<ice:column>
<ice:outputText value="#{_a}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
</ice:panelTabSet>
</h:form>

If you navigate to tab 2, the first bean´s init method will be called ("B Created"). Then navigate to tab 3 and you will see the same for A ("A created"). If you swap out the h:dataTable/h:column and replace it with it´s ice equivalents and retry the above test, both B and A are created at the same time when you click on tab 2 (("B Created" & "A Created"). Having all getters called can hurt performance since they may contain expensive logic such as DB accesses, etc..

Consider the following source code (BeanA and BeanB source is the same):

@SessionScoped
public class BeanA implements Serializable
{
@PostConstruct
public void init(){
System.out.println("A Created ");
}

public List<String> getA(){
return Arrays.asList("A", "A");
}
}

and the view:

<ice:panelTabSet>
<ice:panelTab label="1">
</ice:panelTab>
<ice:panelTab label="2">
<ice:dataTable value="#{beanB.b}" var="_b">
<ice:column>
<ice:outputText value="#{_b}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
<ice:panelTab label="3">
<ice:dataTable value="#{beanA.a}" var="_a">
<ice:column>
<ice:outputText value="#{_a}" />
</ice:column>
</ice:dataTable>
</ice:panelTab>
</ice:panelTabSet>

If you navigate to tab 2, the first bean´s init method will be called ("B Created"). Then navigate to tab 3 and you will see the same for A ("A created"). If you swap out the h:dataTable/h:column and replace it with it´s ice equivalents and retry the above test, both B and A are created at the same time when you click on tab 2 (("B Created" & "A Created"). Having all getters called can hurt performance since they may contain expensive logic such as DB accesses, etc..

Hide

Permalink

Tyler Johnson added a comment - 05/Sep/11 7:16 AM

Mark Collette said:

Ok, basically the problem is that we've got an incomplete implementation of visitTree, which assumes that it needs to iterate over the dataTable rows, when it should not since we're only doing state restoration, that causes the side effect of loading the dataTable's DataModel and thus loading the beans. Nils has already solved this in the ACE dataTable by adding this guard:

public boolean visitTree(VisitContext context, VisitCallback callback) {
boolean ret = false;
if (this.isVisitable(context)) {
boolean visitRows = requiresRowIteration(context); // *** Here ***

int savedIndex = -1;
if (visitRows)

{ // *** Here *** savedIndex = getRowIndex(); setRowIndex(-1); }

...
if (visitRows) setRowIndex(savedIndex); // *** Here ***
...
}

private boolean requiresRowIteration(VisitContext ctx) {
try

{ // Use JSF 2.1 hints if available return !ctx.getHints().contains(VisitHint.SKIP_ITERATION); }

catch (NoSuchFieldError e)

{ FacesContext fctx = FacesContext.getCurrentInstance(); return (!PhaseId.RESTORE_VIEW.equals(fctx.getCurrentPhaseId())); }

}

Show

Tyler Johnson added a comment - 05/Sep/11 7:16 AM Mark Collette said: Ok, basically the problem is that we've got an incomplete implementation of visitTree, which assumes that it needs to iterate over the dataTable rows, when it should not since we're only doing state restoration, that causes the side effect of loading the dataTable's DataModel and thus loading the beans. Nils has already solved this in the ACE dataTable by adding this guard: public boolean visitTree(VisitContext context, VisitCallback callback) { boolean ret = false; if (this.isVisitable(context)) { boolean visitRows = requiresRowIteration(context); // *** Here *** int savedIndex = -1; if (visitRows) { // *** Here *** savedIndex = getRowIndex(); setRowIndex(-1); } ... if (visitRows) setRowIndex(savedIndex); // *** Here *** ... } private boolean requiresRowIteration(VisitContext ctx) { try { // Use JSF 2.1 hints if available return !ctx.getHints().contains(VisitHint.SKIP_ITERATION); } catch (NoSuchFieldError e) { FacesContext fctx = FacesContext.getCurrentInstance(); return (!PhaseId.RESTORE_VIEW.equals(fctx.getCurrentPhaseId())); } }

Ken Fyten made changes - 06/Sep/11 11:48 AM

Fix Version/s		EE-2.0.0.GA_P01 [ 10271 ]
Fix Version/s		2.1 [ 10241 ]
Assignee Priority		P2
Assignee		Mark Collette [ mark.collette ]

Ken Fyten made changes - 06/Sep/11 3:26 PM

Assignee

Mark Collette [ mark.collette ]

yip.ng [ yip.ng ]

Ken Fyten made changes - 06/Sep/11 3:57 PM

Assignee Priority

P2

P1

Hide

Permalink

yip.ng added a comment - 07/Sep/11 4:57 PM - edited

The above suggested code changes were already in UIData originally. We just removed them in UISeries and introduced the bug. These can be reinstated by copying visitTree() from UISeries into HtmlDataTable and reinstating the original code.

However, this copying produces other problems. Four methods used by visitTree() are private to UISeries. See screenshot 1. Do we then copy them as well? (And others used by them, and so on.) Two of them (doVisitChildren and visitFacets) can be reverted similarly back to the UIData versions with checking of visitRows. The other two (visitColumnFacets and visitColumnsAndRows) have more non-trivial changes to the corresponding versions in UIData (but differently named) and need more understanding.

Or do we want to make changes directly in UISeries?

And with these changes, the code is reverting back to be more and more like the orignal UIData visitTree logic now.

Show

yip.ng added a comment - 07/Sep/11 4:57 PM - edited The above suggested code changes were already in UIData originally. We just removed them in UISeries and introduced the bug. These can be reinstated by copying visitTree() from UISeries into HtmlDataTable and reinstating the original code. However, this copying produces other problems. Four methods used by visitTree() are private to UISeries. See screenshot 1. Do we then copy them as well? (And others used by them, and so on.) Two of them (doVisitChildren and visitFacets) can be reverted similarly back to the UIData versions with checking of visitRows. The other two (visitColumnFacets and visitColumnsAndRows) have more non-trivial changes to the corresponding versions in UIData (but differently named) and need more understanding. Or do we want to make changes directly in UISeries? And with these changes, the code is reverting back to be more and more like the orignal UIData visitTree logic now.

yip.ng made changes - 07/Sep/11 5:02 PM

Attachment

screenshot-01.png [ 13509 ]

Hide

Permalink

Ken Fyten added a comment - 07/Sep/11 5:21 PM

What was the justification for making these UISeries changes originally?

Show

Ken Fyten added a comment - 07/Sep/11 5:21 PM What was the justification for making these UISeries changes originally?

Hide

Permalink

yip.ng added a comment - 07/Sep/11 5:59 PM

~~ICE-5815~~. According to my comments there, visitTree() and related methods were just copied from UIData. Different version of UIData than now (Mojarra 2.1.2)?

Show

yip.ng added a comment - 07/Sep/11 5:59 PM ICE-5815 . According to my comments there, visitTree() and related methods were just copied from UIData. Different version of UIData than now (Mojarra 2.1.2)?

Hide

Permalink

Ken Fyten added a comment - 07/Sep/11 6:02 PM

Then I'd suggest we use the current code from Mojarra 2.1.2 that should resolve this issue.

Show

Ken Fyten added a comment - 07/Sep/11 6:02 PM Then I'd suggest we use the current code from Mojarra 2.1.2 that should resolve this issue.

Hide

Permalink

yip.ng added a comment - 09/Sep/11 3:24 PM - edited

Looks like old UIData code was copied from Mojarra 2.0.2. Suggested fix (by Mark above) started to appear in 2.0.3.

Checked to make sure no other changes made to copied code since ~~ICE-5815~~.

Re-copied code from latest Mojarra version (2.1.3). Fix automatically included and this JIRA's issue automatically solved. Tested with Tyler-supplied test app., transplanted into compat showcase.

Re-applied fix for ~~ICE-5815~~. Tested with test case mentioned in ~~ICE-5790~~: http://server:8888/svn/repo/qa/trunk/Regression-Icefaces2/Nightly/ICE-3057

Revision: 25440

Modified : /icefaces2/trunk/icefaces/compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java

Revision: 25441

Modified : /icefaces2/branches/icefaces-2.0.x-maintenance/icefaces/compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java

Show

yip.ng added a comment - 09/Sep/11 3:24 PM - edited Looks like old UIData code was copied from Mojarra 2.0.2. Suggested fix (by Mark above) started to appear in 2.0.3. Checked to make sure no other changes made to copied code since ICE-5815 . Re-copied code from latest Mojarra version (2.1.3). Fix automatically included and this JIRA's issue automatically solved. Tested with Tyler-supplied test app., transplanted into compat showcase. Re-applied fix for ICE-5815 . Tested with test case mentioned in ICE-5790 : http://server:8888/svn/repo/qa/trunk/Regression-Icefaces2/Nightly/ICE-3057 Revision: 25440 Modified : /icefaces2/trunk/icefaces/compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java Revision: 25441 Modified : /icefaces2/branches/icefaces-2.0.x-maintenance/icefaces/compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java

yip.ng made changes - 09/Sep/11 4:12 PM

Status	Open [ 1 ]	Resolved [ 5 ]
Resolution		Fixed [ 1 ]

Hide

Permalink

Nicklas Karlsson added a comment - 12/Sep/11 12:42 AM

Do you think there could be a related issue with the rendering of the tree component? I see getters being called for a tree that's on another tab (and having rendered evaluated to false at that point)

Show

Nicklas Karlsson added a comment - 12/Sep/11 12:42 AM Do you think there could be a related issue with the rendering of the tree component? I see getters being called for a tree that's on another tab (and having rendered evaluated to false at that point)

Hide

Permalink

Ken Fyten added a comment - 13/Sep/11 2:40 PM

Nicklas, since panelTabSet uses UISeries for dynamic tabs, it's possible this fix might help you also. If not, please create a new JIRA.

Show

Ken Fyten added a comment - 13/Sep/11 2:40 PM Nicklas, since panelTabSet uses UISeries for dynamic tabs, it's possible this fix might help you also. If not, please create a new JIRA.

Ken Fyten made changes - 04/Oct/11 3:34 PM

Fix Version/s		2.1-Beta [ 10291 ]
Fix Version/s	2.1 [ 10241 ]

Hide

Permalink

Nicklas Karlsson added a comment - 06/Oct/11 3:05 AM

It appears as there has been a regression regarding f:ajax usage introduced with this issues.

Given a bean like


@Named 
@SessionScoped 
public class Bean implements Serializable 
{ 
	private String s; 

	public void change(ValueChangeEvent e) 
	{ 
		System.out.println(e); 
	} 

	public String getS() 
	{ 
		return s; 
	} 

	public void setS(String s) 
	{ 
		this.s = s; 
	} 
}

and a view like

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" 
	xmlns:h="http://java.sun.com/jsf/html" 
	xmlns:f="http://java.sun.com/jsf/core" 
	xmlns:ice="http://www.icesoft.com/icefaces/component" 
	xmlns:ui="http://java.sun.com/jsf/facelets" > 
<f:view contentType="text/html"> 
<h:head> 
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 
	<ice:outputStyle href="./xmlhttp/css/rime/rime.css"/> 
	<title>ICEfaces</title> 
</h:head> 
<h:body> 
	<h:form> 
		<ice:panelTabSet> 
			<ice:panelTab label="tab"> 
				<h:selectOneMenu value="#{bean.s}" valueChangeListener="#{bean.change}"> 
					<f:selectItem noSelectionOption="true" itemLabel=""/> 
					<f:selectItem itemValue="a"/> 
					<f:selectItem itemValue="b"/> 
					<f:ajax event="change" execute="@this" render="@form"/> 
				</h:selectOneMenu> 
			</ice:panelTab> 
		</ice:panelTabSet> 
	</h:form> 
</h:body> 
</f:view> 
</html>

the eventlistener is never fired, values are not updated in the model etc.

Moving the f:selectOneMenu out of the panelTabSet makes it work again.

Show

Nicklas Karlsson added a comment - 06/Oct/11 3:05 AM It appears as there has been a regression regarding f:ajax usage introduced with this issues. Given a bean like @Named @SessionScoped public class Bean implements Serializable { private String s; public void change(ValueChangeEvent e) { System .out.println(e); } public String getS() { return s; } public void setS( String s) { this .s = s; } } and a view like <?xml version= "1.0" encoding= "UTF-8" ?> <!DOCTYPE html PUBLIC "- //W3C//DTD XHTML 1.0 Transitional//EN" "http: //www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" > <html xmlns= "http: //www.w3.org/1999/xhtml" xmlns:h= "http: //java.sun.com/jsf/html" xmlns:f= "http: //java.sun.com/jsf/core" xmlns:ice= "http: //www.icesoft.com/icefaces/component" xmlns:ui= "http: //java.sun.com/jsf/facelets" > <f:view contentType= "text/html" > <h:head> <meta http-equiv= "Content-Type" content= "text/html; charset=UTF-8" /> <ice:outputStyle href= "./xmlhttp/css/rime/rime.css" /> <title>ICEfaces</title> </h:head> <h:body> <h:form> <ice:panelTabSet> <ice:panelTab label= "tab" > <h:selectOneMenu value= "#{bean.s}" valueChangeListener= "#{bean.change}" > <f:selectItem noSelectionOption= " true " itemLabel=""/> <f:selectItem itemValue= "a" /> <f:selectItem itemValue= "b" /> <f:ajax event= "change" execute= "@ this " render= "@form" /> </h:selectOneMenu> </ice:panelTab> </ice:panelTabSet> </h:form> </h:body> </f:view> </html> the eventlistener is never fired, values are not updated in the model etc. Moving the f:selectOneMenu out of the panelTabSet makes it work again.

Evgheni Sadovoi made changes - 11/Oct/11 8:59 AM

Link

This issue is duplicated by ~~ICE-7314~~ [ ~~ICE-7314~~ ]

Ken Fyten made changes - 14/Oct/11 10:50 AM

Assignee

yip.ng [ yip.ng ]

Mark Collette [ mark.collette ]

Ken Fyten made changes - 17/Feb/12 5:16 PM

Status

Resolved [ 5 ]

Closed [ 6 ]

Repository	Revision	Date	User	Message
ICEsoft Public SVN Repository	#25440	Fri Sep 09 09:47:03 MDT 2011	yip.ng	~~ICE-7185~~: ice:dataTable getters called for unrendered panelTabs.
				Files Changed
				MODIFY /icefaces2/trunk/icefaces/compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java

Repository	Revision	Date	User	Message
ICEsoft Public SVN Repository	#25441	Fri Sep 09 10:20:05 MDT 2011	yip.ng	~~ICE-7185~~: ice:dataTable getters called for unrendered panelTabs.
				Files Changed
				MODIFY /icefaces2/branches/icefaces-2.0.x-maintenance/icefaces/compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java

ice:dataTable getters called for unrendered panelTabs

Details

Description

Attachments

Issue Links

Activity

People

Dates