[FIXED] GXT 2.1.0 WidgetComponent Bug

[mnilson]

Now that WidgetComponent calls setParent and removeFromParent I believe it should be implementing hasWidgets. Otherwise if you insert a WidgetComponent into a Container, removing it from the container, and then try inserting it into a Container again the call to Widget.removeFromParent() throws an IllegalStateException. Image is the widget in particular that I am trying to move around between containers.

Here is the relevant part of the stack trace.

java.lang.IllegalStateException: This widget's parent does not implement HasWidgets
	at com.google.gwt.user.client.ui.Widget.removeFromParent(Widget.java:117)
	at com.extjs.gxt.ui.client.widget.WidgetComponent.<init>(WidgetComponent.java:54)
	at com.extjs.gxt.ui.client.widget.Container.wrapWidget(Container.java:628)
	at com.extjs.gxt.ui.client.widget.LayoutContainer.insert(LayoutContainer.java:201)
	at com.extjs.gxt.ui.client.widget.LayoutContainer.add(LayoutContainer.java:116)

thanks,
Michael

[cravemusic]

I've run into this exact same problem as well -- I have a custom widget which is continually swapping out the components inside of the outer container. I've had no problem with that code before this release.

[Adam Ward]

I have the exact same issue, including the fact that we are adding/removing an Image object to the same container. If you use the same object reference, it seems to break. Here is some sample code:

public class WidgetComponentBug implements EntryPoint {
	/**
	 * This is the entry point method.
	 */
	public void onModuleLoad() {
		final LayoutContainer lc = new LayoutContainer(new FitLayout());
		final Image image = new Image("http://www.extjs.com/assets/images/extjs2.png");
		lc.setSize(200, 200);
		
		lc.add(image);
		
		VerticalPanel vp = new VerticalPanel();
		vp.add(lc);
		
		Button button = new Button("Swap Pics");
		button.addSelectionListener(new SelectionListener<ButtonEvent>() {
			
			@Override
			public void componentSelected(ButtonEvent ce) {
				lc.removeAll();
				lc.add(image);
				lc.layout();
			}
		});
		vp.add(button);
		RootPanel.get().add(vp);
 	}
}

[Adam Ward]

P.S. the "lc.setSize(200, 200)" is not necessary to repro the bug.

[Adam Ward]

The following code DOES NOT throw the exception:

public void onModuleLoad() {
		final LayoutContainer lc = new LayoutContainer(new FitLayout());
		final Image image = new Image("http://www.extjs.com/assets/images/extjs2.png");
		final WidgetComponent wc = new WidgetComponent(image);
		lc.setSize(200, 200);
		
		lc.add(wc);
		
		VerticalPanel vp = new VerticalPanel();
		vp.add(lc);
		
		Button button = new Button("Swap Pics");
		button.addSelectionListener(new SelectionListener<ButtonEvent>() {
			
			@Override
			public void componentSelected(ButtonEvent ce) {
				lc.removeAll();
				image.setUrl("http://www.google.com/intl/en_ALL/images/logo.gif");
				lc.add(wc);
				lc.layout();
			}
		});
		vp.add(button);
		RootPanel.get().add(vp);
 	}

The key difference between this code and the code I posted before is that the object that is being added/removed from the LayoutContainer is a WidgetComponent instead of an Image object. This workaround has fixed my problem. Perhaps better documentation guiding users of the newer APIs and framework paradigms could have helped to avoid this type of breakage

[mnilson]

The following code DOES NOT throw the exception:
...

I understand that your work around will avoid the bug; I have chosen a different workaround for my particular case. I still maintain that this is a bug though. If a widget needs to be wrapped in a WidgetContainer then it either needs to be the developers responsibility to wrap the widget (ie container shouldn't call wrapWidget as a convenience method) or GXT needs to be completely responsible for handling the widget wrapping. I'm sure the former (removing the call to wrapWidget) would cause many breaking changes and that this is just a small oversight in the recent changes to WidgetComponent that will get fixed.

[cravemusic]

I completely agree with mnilson's statement. To rephrase it simply, there should be consistency in the wrapping API, and this is the bug that should be addressed.

[darrellmeyer]

This bug is fixed in the releases/2.1 branch and is now available in the 2.1.1-beta release available here.

[mnilson]

Thanks