PDA

View Full Version : Resize issue in panel vs. container in 4.0.5



BillHubbard
18 Aug 2013, 8:26 PM
I'm stuck working in a 4.0.5 environment, so please don't suggest I upgrade.
I have created a widget that extends Ext.container.Container that I use as a base for building applications that need this type of container. I have an app that dynamically loads in other apps, depending on the selection from a combo box. This works perfectly fine.

However, I needed to change my widget to extend Ext.panel.Panel, instead, and now I have an issue where, upon rendering, the panel takes on a fixed size, so that when I dynamically load in another app and render it, it gets chopped off because the panel does not resize itself (vertically). But if I close this inner app and select it again, suddenly there it is in full view.

I've tried calling doLayout and doComponentLayout on various containers in the parent and child apps, but to no avail. What is the magic method to call to get the panel to resize to fit its content, and why is it that Container can do this, but Panel cannot?

evant
18 Aug 2013, 8:32 PM
You'll need to post some kind of test case, it's too difficult to say without seeing anything.

BillHubbard
18 Aug 2013, 11:27 PM
You're killing me. Can't you recommend something to try? Is doLayout or doComponentLayout even on the right track? Where does a panel compute its height? The height is applied to the element in the DOM, so it is obviously computed in JS. What methods are available to adjust/refresh a panel? There's some case where it is adjusting properly, so I know if I make the right call somewhere it will fix it.

BillHubbard
19 Aug 2013, 2:14 AM
OK, here's the issue. It appears Container uses 'auto' layout, and Panel uses 'dock' layout, so Panel is a size-managed container. That's why everything worked smoothly with Container but not with Panel.

My main view panel defines an empty container (div) with an id, and based on a selection from a combox box, it instantiates a view and attaches it to this div (via renderTo: id). This is the simplified description, anyway. The longer answer reveals that the main view does not directly render the child view, but merely passed along the id of the div to a selected controller that ultimately renders the view, so the bottom line is, my main view does not have visibility to the child view being rendered, so cannot pass along an event listener to it (unless I spend a *&#$-load of time modifying ALL the child apps to pass along a callback through all their controllers to apply to all the views).

The problem is, the main panel renders to size before the inner child panel is rendered after some user interaction. The resize event from this child panel is not propagating to my parent app, so it cannot respond with a doComponentLayout call to update the content. So, SOMEHOW, my main view needs to respond to the resize event of the child app so I can call doComponentLayout. How in the #&^$ do I capture this without having to modify all my existing code as mentioned above, and without having to carry this burden with any and all new development I do down the line?

Is there some way to obtain a reference to the parent view through the div id?

tobiu
19 Aug 2013, 10:33 AM
Hi Bill,

although you do not want us to suggest it, you should at some point consider to upgrade. Between 4.0.5 and the current version are hundreds of bugfixes and improvements, so you might waste time with things that already work fine.

Regarding the issue: Panel is just an extension of Container which optionally adds a header and toolbars. Both, by default, use layout auto but you can switch this to any layout we provide.

Just use the config:


layout : {
type : 'vbox',
align : 'stretch'
}


(or use layout fit, anchor, etc.)

Without a short testcase it is impossible for me to say what and why it is breaking, but I can give you the recommendation that for most use cases the layout manager takes care and you do not need to resize child components.

I also strongly recommend to not work on DOM level in case you are dealing with basic framework components (for really custom things it can make sense).

When you have a panel and want to add a container, you can simply use:


myPanel.add(myContainer); // or myPanel.insert(...)


in case the panel has a layout, it will take care about it.

BillHubbard
20 Aug 2013, 9:13 AM
Thanks for the reply. We are unable to upgrade ExtJS as of 4.1.0 due to a critical defect which has yet been resolved that prevents later versions of ExtJS from running in our environment. I've been back and forth on this, and can get no help unless I can provide a standalone example of the problem that Sencha can look at, which I have explained repeatedly that we cannot provide, and I am hoping that one day we can get someone from Sencha to look at it in our environment. Believe me, I would like nothing more than to upgrade, and we will be looking to try again in November.
For reference, you can follow these threads:
http://www.sencha.com/forum/showthread.php?232229-ExtJS-4.1.1-Ext.require-does-not-call-callback-if-provided
http://www.sencha.com/forum/showthread.php?256407-4.1.1-ExtJS-is-complaining-about-missing-files-that-aren-t-missing&p=938503

As for Panel, if you look at the code, it uses the 'dock' layout. Maybe that has changed since 4.0.5/4.0.7, but what I have does not use 'auto' - this much became painfully evident as I explored my issue.

As for your suggestion to use add, unfortunately I don't currently have that option. In our environment, we embed multiple MVC apps on a page, so we have a loader method that launches an app, and we need to pass it a renderTo id to tell the child app where to attach its main view. Perhaps I can think about adding a callback to this method that will provide a reference to the child view so the callback can perform the add (and similarly I would need a remove as well) - unless I can pass in a reference to the parent view, in which case the child app can call add/remove directly on it. That's definitely an idea for a (near) future update to our code.