PDA

View Full Version : [UNKNOWN][2.x,3.0.0] autoRender config option for Ext.Window



Condor
3 Aug 2009, 4:12 AM
The Ext.Component autoRender config option (not yet documented) has been around since Ext 2.0a1, and it could be very useful for an Ext.Window.

Unfortunately, the autoRender config option is completely ignored by Ext.Window show().

Suggested fix:

Ext.override(Ext.Window, {
show : function(animateTarget, cb, scope){
if(!this.rendered){
// copied from Ext.Component.show()
this.render(Ext.isBoolean(this.autoRender) ? Ext.getBody() : this.autoRender);
}
if(this.hidden === false){
this.toFront();
return this;
}
if(this.fireEvent('beforeshow', this) === false){
return this;
}
if(cb){
this.on('show', cb, scope, {single:true});
}
this.hidden = false;
if(animateTarget !== undefined){
this.setAnimateTarget(animateTarget);
}
this.beforeShow();
if(this.animateTarget){
this.animShow();
}else{
this.afterShow();
}
return this;
}
});

Animal
3 Aug 2009, 4:16 AM
Not sure I get this.

so autoRender is the element to automcatically render to?

This obfuscates the API. That interferes with renderTo.

Condor
3 Aug 2009, 4:34 AM
renderTo takes precedence over autoRender, because renderTo renders the component immediately, leaving the autoRender config option unused.

But you don't always want to render a Window immediately. You often only want to render just before showing.

Using autoRender is a replacement for:

if(!win.rendered){
win.render(autoRenderEl);
}
win.show();

ps. I didn't invent the autoRender config option. It's already in Ext.Component show() and actively used by Ext.Tip and descendants.

Animal
3 Aug 2009, 4:41 AM
Could be useful... I've had the following override around for a while which allowed specification of a Container into which to auto render.



Ext.override(Ext.Component, {
// Configured with renderToContainer and floating. Render on first show.
show: Ext.Component.prototype.show.createInterceptor(function() {
if (this.floating && !this.rendered && this.renderToContainer && this.renderToContainer.rendered) {
this.render(this.renderToContainer.body || this.renderToContainer.el);
}
})
});


But in your scenario - the Window... If the default rendering visibility is going to be hidden, then it should simply defer the rendering until the first show and still use renderTo at show time

More, sublty different configs get confusing.

Condor
3 Aug 2009, 4:53 AM
But in your scenario - the Window... If the default rendering visibility is going to be hidden, then it should simply defer the rendering until the first show and still use renderTo at show time

That would completely break backward compatibility.

If I create a Window with a FormPanel and specify a renderTo:Ext.getBody() I expect the window to be rendered immediately, so I can access the formpanel fields.

And, as I said, the autoRender config option already exists, so you should ask Jack why he introduced it in rev. 977 (Wow, that's old. Isn't that pre-2.0a1?).

Animal
3 Aug 2009, 4:59 AM
Hm.. I didn't see it. I'm not sure if I can summon up the prose to describe it!

Condor
3 Aug 2009, 5:14 AM
How about:

autoRender : Mixed

Specifies if and where this component will be rendered when show() is called (and the component isn't rendered yet).

Possible values:
- false: The component will not be rendered (the component won't be shown).
- true: The component will be rendered into the document body.
- id of an element, a DOM element or an existing Element: Render into the specified element.
(remove the config option for Ext.Window as long as this bugreport isn't processed)

Animal
3 Aug 2009, 5:18 AM
I still don't like it.

I'd prefer a config like deferRender, or renderOnShow which deferred rendering (along with its use of renderTo) until show time.

mjlecomte
3 Aug 2009, 8:49 PM
well, one perk if it's undocumented is that you can pretty much change it to whatever since it falls under the umbrella of being "private" at moment.

mjlecomte
3 Aug 2009, 8:52 PM
Could you explain if you really intend this to be a bug, or if it's more along "should be done" but not a bug? If latter it is more feature request and would be handled differently in svn. I have other "feature requests" pending for code in the library that has fallen out of sync but is currently not causing a bug per se.

Animal
3 Aug 2009, 9:16 PM
Well, I think it's an "action item" for the dev team to consider the design issues raised here, and ensure "render on show" somehow works for all Components.

That's it! I'd like the config renderOnShow: true to defer rendering until the first show call, whereupon it still uses renderTo as the rendering target.

mjlecomte
3 Aug 2009, 9:22 PM
Playing devil's advocate for a bit, why not use deferredRender?

Animal
3 Aug 2009, 9:30 PM
Yes, I think it's a good fit. deferredRender defers until first show in card layouts.

IMHO, this new usage would be for non-layout applications.