gwt detach list

任何人都可以解释我，这个分离列表是什么，它可以在网络中频繁找到“具有现有父窗口小部件的窗口小部件可能不会添加到分离列表中”。我无法找到解释或任何背景信息，只有错误消息。谢谢！gwt detach list

2013-01-15 user1406453

作为memory leak mitigation部分（其中大部分是，如果不仅在需要在IE），GWT具有附和分离窗口小部件的概念。当你作为一个孩子添加窗口小部件到另一个连接部件，该子部件及其所有子控件成为连接过了，相互当你从它的连接父移除小工具，那么它的分离随着所有的孩子。当一个小部件被分离时，它应该释放所有可能导致内存泄漏的资源。

以上构建的树木附件小部件，但树需要一个根。有两种这样的根附带小工具:: RootPanel s总是附加，并且由wrap()创建的小工具ping一个现有DOM元素自动连接。

当页面卸载时，GWT确保分离所有小部件以避免内存泄漏。为此，它跟踪根连接部件在什么所谓的分离列表，并确保所应该小部件是根部件实际上是根源（即其元素是不包含的另一个DOM树中小部件）。该规则的唯一例外是RootPanel.get()，因为它代表其他小部件所在的文档的<body>。

来源

2013-01-15 14:50:42

嗨托马斯，所以好吧，这是一个附加的小部件树。假设这是一个实现细节。通过id透明地访问元素的最佳方式是什么（独立于元素被连接或分离）。另外，更好的是它给了感觉的RootPanel在树中键入了GWT小部件，但我们如何集中访问该注册表？是否有Document.getWidgetById（）：Widget方法？ –

因为代码是相当原始的：它依赖于间接假设：在 RootPanel.isElementChildOfWidget（Element element）中，我们看到这个注释：走上DOM层次结构，寻找具有事件侦听器集的任何小部件。虽然它在一般情况下不可靠，一个小部件将始终设置它的元素的事件监听器，但如果小部件被连接，它*是*可靠的。它将在这种情况下。 –

分离列表是当页面卸载时要分离的小部件列表（source，仅猜测其中一个来源）。
基本上（下面不是一个完整的解释，如果你愿意阅读官方的google documentaion，GWT是非常好的文档），在GWT中，当你创建一个Widget时，那个Widget不会被显示，直到它被添加到RootPanel ，或附加到RootPanel的任何窗口小部件（成为它的父窗口）。有些操作（比如我之前指出的一个链接）会导致一个小部件从RootPanel中分离出来;但是，您不能在嵌入父级控件的窗口小部件上调用RootPanel.detachNow(widget)。这种呼叫会引起你所要求的例外。

来源

2013-01-15 13:50:04 ThanksForAllTheFish

回答

相关问题