Done. I didn't know how verbose I should be on the error message. Please advise :-)
On Wed, May 4, 2011 at 2:04 PM, Ray Ryan <[email protected]> wrote: > I'd be inclined to start with a) and see what happens. > > > On Wed, May 4, 2011 at 10:02 AM, <[email protected]> wrote: > >> >> >> http://gwt-code-reviews.appspot.com/1427812/diff/1/user/src/com/google/gwt/user/client/ui/AttachableHTMLPanel.java >> File user/src/com/google/gwt/user/client/ui/AttachableHTMLPanel.java >> (right): >> >> >> http://gwt-code-reviews.appspot.com/1427812/diff/1/user/src/com/google/gwt/user/client/ui/AttachableHTMLPanel.java#newcode205 >> user/src/com/google/gwt/user/client/ui/AttachableHTMLPanel.java:205: if >> (isFullyInitialized()) { >> On 2011/05/04 16:47:17, rjrjr wrote: >> >>> This seems pretty unexpected. I would have thought it would either be >>> >> an error >> >>> (RuntimeException), or else that I would do the opposite of this: >>> >> replace my >> >>> existing element with the new one. >>> >> >> I'd be totally fine with a RuntimeError, it'll probably be m ore >> manageable in the long-term. I was trying to support this because even >> though it's less efficient, we can still make it work. The scenario here >> is: >> >> 1-) Build Attachable tree. This includes calling all the render() stuff >> and so on. Let's assume that this particular AttachableHTMLPanel is in >> the middle of the tree. >> >> 2-) For some reason do something to this particular panel (that's in the >> middle of the tree) that calls its getElement() [let's say attach it to >> the document]. This triggers the process of building the widget tree as >> if this panel was the root (i.e., hidden div, set innerHTML, getting >> elements for all children and initializing them). At this point >> everything works >> >> 3-) Now you go and attach the "real" root of the tree, an ancestor of >> this panel. We can do one of 3 things: >> (a) throw an error. You probably didn't mean to do this as it's less >> efficient >> (b) replace the element that our parent assigned us (along with its >> subtree) with the subtree we already built in step 2 >> (c) re-do everything in step 2, ignoring the fact that we already >> initialized all children widget >> >> I think (a) would be ideal, specially for debugging purposes. Honestly I >> implemented (b) because I was a little afraid and wanted to be as >> backwards-compatible as possible. I don't think (c) would work >> out-of-the-box, as we'd have to support initializing Widgets twice >> (i.e., re-setting the element, etc.) >> >> Makes sense? >> >> >> http://gwt-code-reviews.appspot.com/1427812/ >> > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
