Dynamic form in a window covering window furniture. Why?

[ratkins]

SmartGWT 2.2, GWT 2.1, FireFox 3.6.12.

I'm trying to create the simplest possible login form, and I get the login form elements occluding the title bar of the window I'm trying to put them in (see attachment). Why? My code looks like this:

public class MyEntryPoint implements EntryPoint {

    public void onModuleLoad() {
		DynamicForm loginForm = new DynamicForm();
		loginForm.setWidth100();
		loginForm.setHeight100();
		
		TextItem usernameTextItem = new TextItem();
		usernameTextItem.setTitle("Username");

		TextItem passwordTextItem = new TextItem();
		passwordTextItem.setTitle("Password");
		
		ButtonItem buttonItem = new ButtonItem();
		buttonItem.setTitle("Log in");
		buttonItem.setAlign(Alignment.RIGHT);

		loginForm.setFields(usernameTextItem, passwordTextItem, buttonItem);
		
		Window window = new Window();
		window.setTitle("Log in");
		window.setSize("300px", "120px");
		window.addChild(loginForm);
		window.centerInPage();
		
    	RootLayoutPanel.get().add(window);
    }
}

Cheers, Robert.

[smartgwt.dev]

Try window.draw() instead of RootLayoutPanel.get().add(window);

In general prefer rendering your Smart GWT app by draw() ing the top most Canvas / container instead of adding it to RootPanel.get().

[Isomorphic]

Aside from this, you are also using addChild() instead of addItem().

[ratkins]

addItem() fixed it, modulo some centering issues which I guess I can overcome by putting the DynamicForm in a .setLayoutAlign'd VLayout or something.

Thanks for the help, but the meta-question is which higher-level abstraction should I be using which makes frustrating eff-ups of this nature impossible?

Cheers, Robert.

[Isomorphic]

Windows support children (self-positioned), members (vertically stacked by the superclass VLayout - includes the built-in components a Window generates such as the header) and items (placed within the body).

Increasingly specific APIs on subclasses, with inherited APIs from superclasses, is typical of object-oriented programming in general.. not sure what you're looking for. Following samples always helps..

[ratkins]

Ok, given that what I'm really trying to do is create a demonstration of SpringSecurity protecting a SmartGWT app, I don't care about anything lower level than what I can see.

Having the APIs necessary to *create* a window's title bar et al exposed, when all I want to do is say, "Give me a Dialog-box looking thing with username and password fields and a button which says 'log in'" significantly confuses the issue. So what environment should I be using in order to give me only the stuff I'm interested in? Or is the done thing to write your own wrapper?

And I am following examples. All of which have a *slightly* different setup than the one I'm working with on some level (UiBinder + GWT, rather than SmartGWT, or whatever.) It's tiring.

Cheers, Robert.

[Isomorphic]

Don't really follow the critique of Window. A Window is a pretty core component. It's going to have a lot of APIs because it needs to do a lot of things.

You realize there's a pre-built LoginDialog?

[ratkins]

I'm not criticizing Window. It's a fine class, upstanding member of the API and all. I know it's a busy man and leads a complicated life. My critique is that I don't obviously see a subset of the API which is operating at the same level of abstraction that I am. To wit, a higher one in which drawing a text box half on top of a window title bar is something you'd never want to do.

Is there one (in Java), do people tend to write their own, should I be using something like UiBinder or is there something in Pro/Enterprise?

(Also, I can find Dialog, but no LoginDialog in the SmartGWT javadoc.)

Cheers, Robert.

[Isomorphic]

People who want to work at an abstraction level where they can put things in Windows also frequently want to put some custom widget in the header or add their own footer, so the APIs appear at the same level.

The next level of abstraction is probably Visual Builder (in Pro/EE). There you could not accidentally use addChild() and end up with your widget in the header. But as is typical of tools that raise the abstraction level, you also could not place a widget in the header at all.

[ratkins]

Speaking for myself, I do see a level where if I wanted to put something in a window's title bar or footer I'd say something like window.addToTitleBar(widget) or window.addToFooter(widget), but I understand you don't have the resources to create the ideal abstraction for every user.

I'll investigate the visual builder.

Cheers, Robert.