[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..

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

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

Attachment

screenshot-01.png [ 13509 ]

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

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

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

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

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 ]

ice:dataTable getters called for unrendered panelTabs

Details

Description

Attachments

Issue Links

Activity

People

Dates