Please do something to better explain "Layout run failed" errors.

[brian428]

I have an app that runs fine in 4.1.3. Upgrading to 4.2 RC shows a "layout run failed" error in the console, but because it tells you absolutely nothing, I have no idea what component is causing this. Please add at least the class name, id/itemId, or something (anything) to this error log message, because as it is now there is no way to determine anything about these errors.

[skirtle]

Have you tried running it through the Page Analyzer? That may give you more information.

In general though, it isn't as simple as you might think to give feedback on why a layout failed. While there may only be a single omission causing the failure it isn't necessarily possible to know which of the many components and layouts involved is the one that is misconfigured.

Each container's layout specifies a series of constraints that must be satisfied but in isolation there often isn't a unique solution for those constraints. It's only in the context of all the layouts taken together that the constraints combine to specify a unique solution for all of the equations involved. When a layout fails it usually means that there aren't enough constraints to calculate all of the sizes involved but adding a new constraint can be done is so many ways that the library can't realistically guess which one was omitted.

For example, if the layout run fails to calculate the widths it could be because the parent container was missing a width configuration. Or maybe the container was supposed to shrink-wrap its children and it is the children that are missing a width configuration. For two components it isn't too bad but when they're nested dozens deep the problem could be with any one of them.

In short, the layouts often know that something is missing but it doesn't necessarily know what.

The Page Analyzer is your best bet as it can give you an indication of which part of the layout hierarchy caused the failure. It can't necessarily isolate the problem to a single layout but it can flash red lights on the layout branch that failed, narrowing your search.

[brian428]

Thanks, I had never even heard of the page-analyzer, and it took some Googling to even find out what it is.

Running my app through this tool does indicate a problem, but as you say, it doesn't really identify what the problem actually is.

I'm attaching a screen shot in case someone else might be able to better interpret what it is saying. The trigger text "hamur-view-impact-associatedImpacts-1036.containerChildrenSizeDone:dom (=undefined) - dirty: false - setBy: ??" doesn't tell me much. It also seems odd that the two child layouts under this one are both green/ok.

Any ideas? Could this be a bug in 4.2 RC?

[evant]

Could be a bug.

Since everything is either calculated/configured they tend to be the most solid kinds of layouts. The only thing that jumps out is having an anchor layout at the root, typically you don't see that. What if you replace that with say, a card layout.

[Animal]

If associatedImpacts is a 'west' or 'east' region, and it is anchor layout, it needs to know its width in order to width its child components.

[brian428]

If associatedImpacts is a 'west' or 'east' region, and it is anchor layout, it needs to know its width in order to width its child components.

Thanks, Animal. Here's the jist of the border layout and the associatedImpacts. It's actually in the center region, and while that region doesn't have a width, the west region has an explicit width, so that the center and south regions take up the remaining screen width.

layout: "border"


items: [
  itemId: "impactTree"
  region: "west"
  width: 325
  split: true
  collapsable: true
  xtype: "hamur-view-impact-impactTree"
,
  itemId: "associatedImpacts"
  region: "center"
  xtype: "hamur-view-impact-associatedImpacts"
,
  itemId: "availableImpacts"
  region: "south"
  height: "50%"
  split: false
  collapsable: true
  collapsed: true
  weight: -100
  xtype: "hamur-view-impact-availableImpacts"
]

And in associatedImapcts, I'm using:

layout: "anchor"
anchor: "100% 100%"

Do you see anything wrong with this? Also, again as far as I can tell, it works under 4.1.3 with no issue. Also, while the layout run failed message appears in the log, the app actually SEEMS to work correctly. That said, the layout run failing obviously can't be ignored.

Thanks again,

Brian

P.S. On the off chance that this means more to you than it does to me, I did a "build layout run spec" in the page analyzer, and this is the relevant section. The odd thing seems to be that the width and height for associatedImpacts seems to be getting calculated fine. Sorry to blast all this code at you, but I'd rather include too much than not enough and end up missing something important:

"children" : [{
  "allDone" : false,
  "done" : false,
  "id" : "anchor-1077",
  "type" : "anchor",
  "name" : "hamur-view-impact-associatedImpacts-1036<anchor>",
  "blocks" : [],
  "boxParent" : null,
  "isBoxParent" : true,
  "triggers" : [{
      "name" : "hamur-view-impact-associatedImpacts-1036.containerChildrenSizeDone:dom",
      "prop" : "containerChildrenSizeDone",
      "dirty" : false,
      "missing" : true,
      "setBy" : "??"
    }, {
      "name" : "hamur-view-impact-associatedImpacts-1036-body.height:dom",
      "prop" : "height",
      "value" : 779,
      "dirty" : false,
      "missing" : false,
      "setBy" : "hamur-view-impact-associatedImpacts-1036<dock>"
    }, {
      "name" : "hamur-view-impact-associatedImpacts-1036-body.width:dom",
      "prop" : "width",
      "value" : 1102,
      "dirty" : false,
      "missing" : false,
      "setBy" : "hamur-view-impact-associatedImpacts-1036<dock>"
    }
  ]
  ...

[Animal]

How is mainPanel being sized?

[brian428]

How is mainPanel being sized?

The viewport has a vbox layout, with align: stretch, and the mainPanel item has flex: 1. Within mainPanel, it's using anchor.

[Animal]

Can we see some code?

[brian428]

Can we see some code?

Sure, I can try...I posted the layout info for the border layout and the associatedImpacts earlier. Is there something else that would make sense to see? This is part of a larger client app, so I can't just post everything, and I haven't had a chance to try and create an independent test case since it will take some time to replicate the setup. That said, if you think an independent test case may be the only way to diagnose it, I can try to create one today/tonight.

Thanks,

Brian