理解“布局运行失败”错误记录 [英] understanding "Layout run failure" error logging

查看:144
本文介绍了理解“布局运行失败”错误记录的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在做一些图表工作,并且在图表上没有创建任何内容时,收到一条单行消息布局运行失败。看到这一点,我发现我必须添加一些额外的脚本文件来生成日志文件覆盖这里


布局失败



由于4.1中布局引擎的设计,对于不正确的配置(或错误)导致布局运行失败
可以完成其所有计算,可能是
。当这种情况发生时,布局简单地
停止,已经刷新到DOM的部分结果是
所有可见的。在某些情况下,布局可能是99%完成,
失败可能未被发现或显示为次要视觉异常。在
其他情况下,布局可能会早早失败,并将UI清理成
破碎状态(非常像布局中的JS错误,在以前的
版本中)。



诊断



如果怀疑您看到布局失败,第一步是
启用布局诊断。这是通过用ext-all-dev.js替换正常的
ext-all.js文件,并添加一对额外的
脚本。


< blockquote>

我添加了所需的脚本:

 < script type =text / javascriptsrc =extjs / src / diag / layout / Context.js>< / script> 
< script type =text / javascriptsrc =extjs / src / diag / layout / ContextItem.js>< / script>

现在我得到诊断数据,我不能感觉到 - 似乎没有诊断错误:

  ++ printer< autocontainer> -  size:configured / shrinkWrap 
--statprint-1472< autocontainer> - size:配置/配置
triggeredBy:count = 1
statprint-1472.containerChildrenDone:dom()dirty:false,setBy:?
--chart-1473< draw> - size:shrinkWrap / shrinkWrap
triggeredBy:count = 1
chart-1473.containerChildrenDone:dom(true)dirty:false,setBy:?
++ panel-1474< dock> - boxParent:printer - size:natural / configured
++ panel-1474< autocontainer> - boxParent:printer - size:natural / configured
++ statprint-1472< dock> - size:配置/配置
++ statprint-1472_header< body> [isBoxParent] - size:calculated / shrinkWrap
++ statprint-1472_header< hbox> [isBoxParent] - size:calculated / shrinkWrap
++ statprint-1472_header_hd< autocomponent> [isBoxParent] - size:calculated / shrinkWrap
++ tool-1475< autocomponent> [isBoxParent] - 大小:配置/配置

有没有人知道诊断信息在哪里解释? / p>

解决方案

我发现这些类型的错误通常是以最快的方式解决的。隔离哪个组件配置导致布局失败。从内到外注释掉子组件,用填充html配置替换它们,直到导致失败的组件为零,然后查看可以放回多少内容,直到错误返回,您应该只查看剩下的一些配置,你可以对着文档/示例进行眼球。


I am doing some charting work and got a single line message "Layout run failure" when nothing was being created on the chart. Looking into this I found that I have to add some additional script files to generate the log files as covered here:

Layout Failures

As result of the design for the layout engine in 4.1, it is possible for improper configuration (or a bug) to cause a layout run to fail to complete all of its calculations. When this occurs, the layout simply stops and the partial results that have been flushed to the DOM are all that is visible. In some cases, the layout may be 99% complete and the failure may go undetected or appear as a minor visual anomaly. In other cases, the layout may fail early and leave the UI in a clearly broken state (much like a JS error during layout would do in previous versions).

Diagnostics

The first step if you suspect you are seeing a layout failure is to enable the layout diagnostics. This is done by replacing the normal "ext-all.js" file with "ext-all-dev.js" and adding a couple additional scripts.

I added the required scripts:

<script type="text/javascript" src="extjs/src/diag/layout/Context.js"></script>
<script type="text/javascript" src="extjs/src/diag/layout/ContextItem.js"></script>

And now I get diagnostic data that I can't make any sense of - it doesn't seem to diagnose an error:

++printer<autocontainer> - size: configured/shrinkWrap
    --statprint-1472<autocontainer> - size: configured/configured
        triggeredBy: count=1
            statprint-1472.containerChildrenDone:dom () dirty: false, setBy: ?
        --chart-1473<draw> - size: shrinkWrap/shrinkWrap
            triggeredBy: count=1
                chart-1473.containerChildrenDone:dom (true) dirty: false, setBy: ?
    ++panel-1474<dock> - boxParent: printer - size: natural/configured
    ++panel-1474<autocontainer> - boxParent: printer - size: natural/configured
    ++statprint-1472<dock> - size: configured/configured
        ++statprint-1472_header<body> [isBoxParent] - size: calculated/shrinkWrap
        ++statprint-1472_header<hbox> [isBoxParent] - size: calculated/shrinkWrap
            ++statprint-1472_header_hd<autocomponent> [isBoxParent] - size: calculated/shrinkWrap
            ++tool-1475<autocomponent> [isBoxParent] - size: configured/configured

Does any one know where the diagnostic information is explained?

解决方案

I find these types of errors are often solved the quickest with a comment-out-till-it-goes-away approach to isolating which component config is causing the layout failure. Comment out child components from the inside out, replacing them with a filler html config, until you zero-in on which component was causing the failure, then see how much you can put back until the error comes back and you should be looking at only a few remaining lines of configuration that you can eyeball against the docs/samples.

这篇关于理解“布局运行失败”错误记录的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆