PDA

View Full Version : Deferred rendering change in 3.x



mschwartz
12 Jun 2009, 10:06 AM
I'm seeing a few landmine type bugs appearing in my application that are related to how deferred rendering is done in 3.x vs. how it was done in 2.x.

Specifically, a form that is spread across multiple tabs in a dialog or panel is breaking my submit logic. Why? Fields not rendered on the hidden tabs aren't getting their onRender() called unless the tabs are activated, and thus the Field inheritors aren't adding their fields (hidden or otherwise) to the DOM.

What's the workaround? Is there a way to get 3.x to render those hidden Fields? And can I do it without editing all 200 of my forms? :)

15 Jun 2009, 3:21 AM
Are you explicitly setting deferredRender : false in the tab panels?

mschwartz
15 Jun 2009, 5:01 AM
No.

For the one dialog I found, I had to set it false and it worked, albeit slower (it had to render the hidden tabs).

15 Jun 2009, 5:04 AM
Makes sense.

What you describe has been the behavior since 2.x :)

mschwartz
15 Jun 2009, 5:05 AM
Makes sense.

What you describe has been the behavior since 2.x :)

I wrote that dialog under 2.x and never had this problem. That's why I think there are timebombs in my code - I have to check all 200 dialogs now and set deferredRender to false in the ones that don't work.

Animal
15 Jun 2009, 5:08 AM
Or you could change the default in the TabPanel's prorotype.

'sup to you.

mschwartz
15 Jun 2009, 5:09 AM
This is at least a gotcha for those migrating to 3.x from 2.x.

15 Jun 2009, 5:10 AM
This is at least a gotcha for those migrating to 3.x from 2.x.

negative. 2.x behaves the same way.

Animal
15 Jun 2009, 5:11 AM
deferredRender also defaulted to true in 2.0

So unvisited tabs would not be rendered, and therefore Fields in there would not be rendered, therefore not submitted.

People have been posting questions caused by that ever since 2.0 was released.

15 Jun 2009, 5:14 AM
i remember being one of'em in the 2.x alpha days :)

mschwartz
15 Jun 2009, 6:05 AM
I dug into the code a bit and here's what I found.

The tab that works in 2.2 but not in 3.0 contains a tree widget that is generated from an Ajax call on('render'...). In 2.2, the tree is rendered in the hidden tab (ajax is called), in 3.0 it is not.

When submitting the form (contained in multiple tabs, obviously), the code cascades through the tree doing certain validations. If it has no nodes, it returns invalid. Under 2.2, it cascades through the tree just fine. Under 3.0, it has no nodes.

15 Jun 2009, 6:08 AM
OK, so this is a narrow use case issue, where most people don't embed trees into forms. For the record, i think this change is a positive one. You don't want to render something that is not ready to be rendered.

mschwartz
15 Jun 2009, 6:33 AM
OK, so this is a narrow use case issue, where most people don't embed trees into forms. For the record, i think this change is a positive one. You don't want to render something that is not ready to be rendered.

This really cuts to the heart of the forms stuff I've been posting about for a while.

You DO want the form fields in tabs not activated yet to be instantiated. If they're Ext class objects, there's no rendering required. Field.getValue() would get values of those fields in tabs not yet activated.

As is, forms in tabbed panel 99% of the time require deferredRender: false. Using form.submit() is not going to submit your form fields, as the docs state. Stating that the functionality isn't so hot doesn't make it hot...

15 Jun 2009, 6:36 AM
Gimme some slack, Jack! I pick up what you're putting down. --- Sorry, had to lay down some jive (ever see Airplane?)

There are two conflicting models here. :-\

I don't think this will get much attention until after 3.x is stable.

mschwartz
15 Jun 2009, 6:38 AM
Gimme some slack, Jack! I pick up what you're putting down. --- Sorry, had to lay down some jive (ever see Airplane?)

There are two conflicting models here. :-\

I don't think this will get much attention until after 3.x is stable.

No, it won't, which is fine. 3.0 needs to get out.

And at some point I'll have the time to work on a UX forms package, it's on my todo list.

(My design calls for tabbed forms as well as wizard/cardlayout forms, among others)

Animal
15 Jun 2009, 6:40 AM
They're instantiated.

Components are instantiated as soon as they are added into a Container.

They're just not rendered - they have no presence in the DOM.

Now whether BasicForm's submit Action should collect from the DOM, or from the Collection of Fields usnig getValue is another debate entirely.

I'm of the opinion that getValue should be used.

mschwartz
15 Jun 2009, 6:45 AM
They're instantiated.

Components are instantiated as soon as they are added into a Container.

They're just not rendered - they have no presence in the DOM.

Now whether BasicForm's submit Action should collect from the DOM, or from the Collection of Fields usnig getValue is another debate entirely.

I'm of the opinion that getValue should be used.

on('render') of those components was being called in 2.x, but not in 3.x.

The reason my code broke from 2.x to 3.x is that the tree in the hidden tab was being (nodes) populated via ajax called in on('render') handler.

BTW, disabled fields should be sent to the server - they're fields, not labels.

EDIT: note, I'm digging into this as much as I need to so I can understand the ramifications elsewhere in my code.
EDIT2: and I agree the components are instantiated if not rendered, my mistake.

Animal
15 Jun 2009, 7:01 AM
We are still an HTML page. Disabled fields are not submitted. Read only fields are submitted, disabled fields are not.