PDA

View Full Version : [CLOSED] Card Layout rendering all the items instead of just the activeItem



chandrahasakotyan
27 Jun 2011, 1:58 AM
Here is the reason why it is happening.
In ext-all-debug.js or Ext 4.0.2a version Ext.layout.container.AbstractCard has the function renderChildren defined as following.
Note the call to callParent(), This is resulting in rendering all the child items of the card layout instead of just the activeItem. Removing the call to this.callParent() from this function solved the issue.

How can Sencha be so ignorant about the basic feature of this layout :-?? lack of testing :-??. I had to waste 2 hours to spot this.

renderChildren: function () {
this.getActiveItem();
this.callParent();
},

mitchellsimoens
27 Jun 2011, 7:51 AM
How can Sencha be so ignorant about the basic feature of this layout :-?? lack of testing :-??. I had to waste 2 hours to spot this.

Please remain respectful.

stevil
27 Jun 2011, 6:02 PM
@chandrahasakotyan,

The contract behind Card layout is not that only one component will be rendered/present in the layout at any time, but that only one is visible. It allows a Tab panel to be created, for example, with all of the child panels that will be displayed, so that tab switching will occur very quickly.

This behavior currently works with most Tab panels, including my own.

Render all of the children at once, or render them on demand as Card switches dictate, and you'll wind up with the same result - multiple components rendered to your Card container.

If your requirements do not allow this condition, then what you need is your own extension to Card layout that 1) doesn't allow the rendering of other children at startup, and 2) destroys the existing child before switching to the next (in support of the requirement that only one child should be rendered at a time).

Also, what is the nature of the child items that causes a problem in your situation? Are the children all rendering as visible at once? Are some children "bleeding through" to the foreground?

Configuration/example code that illustrates your approach and/or the incorrect result would be helpful.

If you've found a bug, use the template to report it. It may not be perfect, or completely convenient, but will capture your problem in a way that allows it to be evaluated and worked.

stevil

P.S. If I were to restate the definition of a bug in the same terms that you supplied here, I could say that any bug is the product of ignorance of the conditions that created it in the first place.

chandrahasakotyan
27 Jun 2011, 10:52 PM
Thanks Stevil for the reply.

We have several panels within a Card Layout container.
We would load the first panel out of the card initially and only that will be visible. We are not using Tabs for this instead a menu is provided to switch to the required tab. Also, we do not destroy the previous card upon switching to a new card.

Upon selecting another card through the menu, we make that panel to be active (using cardLayout.setActiveItem).

We have deferredRender set to true for this. Inspite of this all the cards (panels) are invoking the render function of the panels (cards). This delays our initial page loading drastically.

We were using this since Ext 3.0; until Ext 4.0 (I believe so) this was fine. But once we upgraded to 4.0.2a this stopped working. This was painful to find out and fix. That is why I said Sencha was ignorant about this. I have overridden the function and it is working fine for me. I could have kept silent as it is not my job to report this. I wanted other members to benefit from this. That is the reason I have put this. If you were offended sorry about that.

We have customized the usage of Ext JS API; that is why I could not put an example. I should be able to put it in this thread in a day or two.

chandrahasakotyan
27 Jun 2011, 10:56 PM
I think you guys should accept your fault first than getting offended. It is really painful to see issues while upgrading to Ext 4+ from Ext 3+ to. I have no business to keep you guys posted about this bug.

stevil
28 Jun 2011, 3:23 AM
@chandrahasakotyan,

I'm not offended, as I'm not a Sencha employee, the problem isn't mine, and you're not referring to me. I think I was just making a very obscure statement that, when it comes to bug reports at the current time, that you'd get more with honey than vinegar. I've filed quite a few myself in this release!

That said, I can appreciate frustration with bugs, there have been quite a few, and this has been an "interesting" release for us all. All I would say is that I KNOW they want to get everything rock solid, and they're busting their tails to do so.

Definitely fill out the bug template - I've found that since they introduced it, the response time to bug filings has reduced quite a bit!

Cheers,
stevil

vlads
30 Jun 2011, 3:51 PM
I am having the same problem. This is a very serious issue and I am stunned that Sencha refuses to acknowledge the problem...

stevil
1 Jul 2011, 4:13 AM
I am having the same problem. This is a very serious issue and I am stunned that Sencha refuses to acknowledge the problem...

Perhaps they will, if the OP fills out the bug report template that Sencha has requested everyone use.

Ultimately, it seems it comes down to whether or not deferredRender is working or not - it's really that simple. It's been there for ages, it's not a design change. I've actually compared the 3.4 code to 4.0, and 4.0 does appear to support it - the question is whether or not it's working, not ignorance of how it's supposed to work, which is what the OP implies.

If this is a bug report, then report the bug with the template, and see what the Sencha response is. Write a thread that says:

1) I observe X in the code
2) I change your code and my behavior changes from X to Y,
3) I'll provide no other information
4) I'll ask you how you could be so ignorant as to have a possible bug.

What would you expect?

I'm not going to say that there haven't been problems in this release, but people are working pretty damned hard to fix them. Giving them more information certainly doesn't hurt the process.

stevil

iggyn
22 Sep 2011, 11:54 PM
Here is an example of Ext.tab.Panel deferredRender problem:

When using directly tabpanel, deferredRender seems to work. Event 'afterrender' on second tab is not fired on page start.
But, when using in extended class (xtype) 'afterrender' is fired on second tab, despite deferredRender is set to true!

Tested on Ext 4.0.2a, FF4.




Ext.onReady(function(){
//example1
var tabs = Ext.createWidget('tabpanel', {
renderTo: 'tabs1',
width: 450,
activeTab: 0,
deferredRender: true,
items: [{
html: 'a',
title: 'Short Text'
},{
html: 'b',
title: 'Long Text',
listeners: {
scope: this,
afterrender: function()
{ //not fired on page start
console.log('afterrender', this);
}
}
}]
});
//example2
Ext.define('TP1.panel', {
extend: 'Ext.tab.Panel',
alias: 'widget.TP1.panel',
activeTab: 0,
deferredRender: true,
initComponent: function()
{
Ext.apply(this, {
items: [{
html: 'a',
title: 'Short Text'
}, {
html: 'b',
title: 'Long Text',
listeners: {
scope: this,
afterrender: function()
{ //event fired on page start, despite deferredRender=true
console.log('afterrender by xtype', this);
}
}
}]
});
this.callParent(arguments);
}
});
Ext.createWidget('panel', {
renderTo: 'tabs2',
width: 450,
items: {
xtype: 'TP1.panel'
}
});
});

evant
26 Sep 2011, 7:25 PM
Can confirm this issue on 4.0.2a, however I tested it against the latest source build and was unable to reproduce the issue. Marking this as closed.

smartbinary
2 May 2013, 5:11 AM
We're on 4.0.7 and seeing this problem. Would we need to upgrade to 4.1+ to get an official fix?