Diagnosing layout failures

(Update 7-March-2012: the new Page Analyzer described in the blog post has better visualization of layout failures -- removing Sticky on this thread)

First off we want to thank everyone who has downloaded 4.1PR and especially those who have reported their findings. Your input is greatly appreciated.

To assist in this process, we have created a layout "diagnostic layer" that can be used to help isolate the root cause of layout failures. It is enabled by adding a couple script tags after Ext. The two files are not included in normal builds and so cannot be loaded by the dynamic loader (at present). They are located in the src/diag/layout folder in the downloaded zip:

For the vast majority of users, these diagnostics will simply indicate that a layout failure has occurred. Beyond that failure, you can expect problems including JS errors. If a layout failure has occurred, then, it is best to focus only on that issue and not on any subsequent behaviors.

For those that want to write custom layouts, the details from the diagnostic can help identify where results stalled but it will take some time and practice to sort through all the data provided.

A good run will generate a report that says "SUCCESS" while a failed run says "FAILURE". In a failed run, the layout tree is written to the console with "++" indicating completed layouts and "--" indicating unfinished layouts. Something like this (where I have highlighted the missing values):

In the above, I deliberately forced the hbox layout to not publish contentHeight (a value published by container layouts when autoHeight) which caused the body layout to stall since it needed that value (it is triggeredBy it) in order to calculate the header's height. This in turn caused the dock layout to stall because it needed the height to dock the header component. Finally, the viewport was waiting for all of its child items to complete before it could perform its final steps.

Hopefully this tool will be of some assistance externally. It has been of great value to us internally as we have been working out the interactions between the many layout managers in Ext JS.

There is a lot of documentation on the new layout system in layout/Context. It is largely up to date, but needs review since it was written over a month ago.

Feel free to ask questions about custom layouts of course.

I have it on my TODO list to see about simplifying the guts of calculateBodyNaturalWidth and just measure the outer el. There were issues with this in the past, but I think they are largely historical now or will be when I finish up the rest of the "autoWidth" magic... er, logic

I'll definitely be looking at this, as I have a custom field layout that I use extensively.

@stevil,

The field layouts have changed dramatically since PR1. I hope the docs on Base and Labelable explain the new "decorator" tpl's... they could be enough to avoid an override of fieldSubTpl and might be enough to avoid writing a custom layout altogether.

I am very curious to hear your mileage on the new (low-calc) layouts for field.

Am I reading this right? Is the root cause for the layout failure the deepest node in my diagnoses tree?

If you post the raw JSON data I can look at it and see, but the tree displays Red icons for failed layouts and Orange icons for containers with failed child layouts. The key to understanding the root cause is the Triggers which represent the data flow between the layouts. That takes some time to see the patterns there but what you are looking for is some unknown variable (a trigger) that *should* be knowable at the moment of the failure.

Often times the failure comes down to a situation where the layout definition is somehow contradictory and no solution can be found, but it can also be a bug. On that front, there is a bug fix in recent nightly builds to do with constraint handling.