PDA

View Full Version : [FIXED-171][3.0.0] Panel::floatable zindex difficult to override



mjlecomte
2 Aug 2009, 12:43 PM
Admittedly this definitely veers towards feature request, but seems a little short sighted not to just classify it as a bug in a way.

Brought up in this thread:
http://extjs.com/forum/showthread.php?t=76278

Just modify examples/layout/complex.html as follows:

var viewport = new Ext.Viewport({
layout: 'border',
items: [
// create instance immediately
new Ext.BoxComponent({
region: 'north',
height: 32, // give north and south regions a height
autoEl: {
tag: 'div',
html:'<p>north - generally for menus, toolbars and/or advertisements</p>'
}
}), {
// lazily created panel (xtype:'panel' is default)
region: 'south',
contentEl: 'south',
split: true,
height: 100,
minSize: 100,
floating:{zindex:4000},
zindex:5000,
maxSize: 200,
collapsible: true,
title: 'South',
margins: '0 0 0 0'
}, {
region: 'east',
title: 'East Side',
collapsible: true,
floating:true,
//floating:{zindex:4000},

Then just pop in a window via firebug:


w=new Ext.Window({width:100,height:100}).show();

The expectation is that the Window will float above the panels in the viewport. It doesn't though because the zindex for floated layers defaults to 11000 and is not easily changed.

One way to work around this for windows is to use the windows manager zseed, but that's a bit PIA to have to deal with other things like MessageBox, etc.

Two things I notice that should probably be done:
Expose the default zindex for Layer so it's configurable, at moment it's private:


Ext.extend(Ext.Layer, Ext.Element, {
getZIndex : function(){
return this.zindex || parseInt((this.getShim() || this).getStyle('z-index'), 10) || 11000;
},


The other change is with Ext.Panel. At the moment you can pass floatable:true, or you can pass a config object for the layer (but that config will be the ENTIRE config object for the layer unfortunately). So that's a bit PIA if all you want to do is say configure the zindex and not deal with the rest of the configs:


makeFloating : function(cfg){
this.floating = true;
this.el = new Ext.Layer(
Ext.isObject(cfg) ? cfg : {
shadow: Ext.isDefined(this.shadow) ? this.shadow : 'sides',
shadowOffset: this.shadowOffset,
constrain:false,
shim: this.shim === false ? false : undefined
}, this.el
);
},

So instead of blindly using that config you should just have to pass along the stuff you want to modify, so I propose:

// private
makeFloating : function(cfg){
this.floating = true;
var defaults = {
shadow: Ext.isDefined(this.shadow) ? this.shadow : 'sides',
shadowOffset: this.shadowOffset,
constrain:false,
shim: this.shim === false ? false : undefined
},
config = Ext.apply({},defaults, cfg);
this.el = new Ext.Layer(config, this.el);
},

Animal
2 Aug 2009, 11:39 PM
It's not really valid to have a Component that is being managed by a layout floating.

You would use a standalone Window.

mystix
3 Aug 2009, 1:43 AM
It's not really valid to have a Component that is being managed by a layout floating.

You would use a standalone Window.

what about Windows that need to be sized relative to their Container?
-- i'm thinking of Windows which are in Containers.

i'm still of the opinion that Windows should be able to participate in a layout scheme
-- the document.body is, after all, just a stripped down Viewport, which is a Container. thoughts?

Animal
3 Aug 2009, 2:47 AM
floating and being managed by a layout manager are mutually exclusive.

Floating Components cannot be managed by the layout of the Container. They have to be seperate.

You would render them yourself to the Container's getLayoutTarget() and constrain them there.

Animal
3 Aug 2009, 2:50 AM
Unless the layout classes add a special case to skip floating child Components when they loop through them on layout so that they are expempted from interference by any layout schemes.

So then the layout manager is just used as a renderer.

Condor
3 Aug 2009, 2:57 AM
So then the layout manager is just used as a renderer.

So, essentially, you can only use ContainerLayout (layout:'auto').

Maybe there should be a flag in Ext.Component that indicates if it's size and position should be managed by the layout. Floating panels and Ext.form.Hidden would have this flag set to false.

mystix
3 Aug 2009, 3:26 AM
Floating Components cannot be managed by the layout of the Container. They have to be seperate.

You would render them yourself to the Container's getLayoutTarget() and constrain them there.
ah, i see the light now.


So, essentially, you can only use ContainerLayout (layout:'auto').

Maybe there should be a flag in Ext.Component that indicates if it's size and position should be managed by the layout. Floating panels and Ext.form.Hidden would have this flag set to false.
yes, that definitely sounds like a good idea.

[edit]
with this in place, a Container can contain floating Components which are not managed by its layout manager.

mjlecomte
3 Aug 2009, 4:46 AM
Why is this invalid?



new Ext.Panel({
title: 'foo', x:50, y:50,
width: 400,
height: 600,
floating: true, frame: true,
renderTo: document.body
});
new Ext.Window({
width: 300, height:300
}).show();

Animal
3 Aug 2009, 4:48 AM
It's not. It works fine.

mjlecomte
3 Aug 2009, 5:12 AM
Does 'works fine' presume that the window should be behind that panel?

To clarify, with that posted code the window shows up behind (under) the floating panel. If I have a window or MessageBox I presumably want those to show on top of that floating panel.

Animal
3 Aug 2009, 5:15 AM
Panels do not participate with a WindowGroup's indexing scheme.

You could ask it to be under a WindowGroup... the default one in this case:



new Ext.Panel({
style: {
'z-index': Ext.WindowMgr.zseed - 1
},
title: 'foo', x:50, y:50,
width: 400,
height: 600,
floating: true, frame: true,
renderTo: document.body
});
new Ext.Window({
width: 300, height:300
}).show();

mjlecomte
3 Aug 2009, 5:26 AM
Sure, that's probably another way. As I mentioned above, the window z index could be altered. But my point remains that it seems overly complex to modify the z index when floating.

IMO the areas I mentioned before are not as easily overridable/customizable as is typically done throughout framework. I'm just suggesting a couple tweaks to allow configuration to be easier.

Discussion above seems to have gone a different tangent than what my point was: "Ext's ability to extend/configure/override easily".

Animal
3 Aug 2009, 5:31 AM
OK, I agree, makeFloating should be



makeFloating : function(cfg){
this.floating = true;
this.el = new Ext.Layer(Ext.apply({}, cfg, {
shadow: Ext.isDefined(this.shadow) ? this.shadow : 'sides',
shadowOffset: this.shadowOffset,
constrain:false,
shim: this.shim === false ? false : undefined
}), this.el);
},


So you can selectively override defaults.

aconran
30 Oct 2009, 12:58 PM
Committed a fix in r5571 (for Ext 3.1) to allow you to override configurations and not require specifying the whole entire configuration.