Some components I made for fun

These components are not supported in Vaadin 6.2 and above. For 6.2-compatible versions, see the separate posts on

I have made (thus far) four components that were either asked for many times by others, or something I thought was fun to do. There’s a superimmediate text field, a refresher that addresses the progressindicator-polling hack, a crude window manager and swappable password/text field.

You can play around with the examples at
or oogle at/download the code from

Nice! Well done.

I actually
had the swappable password/text field on my TODO for the same reason, but now I don’t have

(…although I had planned to make a plain GWT widget also, so that the whole GWT community could benefit… perhaps I’ll keep that on my TODO if your not planning to do that?)

Best Regards,

Nope, I have no such plans. The world of GWT is still a bit alien to me, so I’ll let the pros do those kinds of things. The window manager is still a bit of black magic, but I have some intentions of extending its features…

Can you elaborate on how the refresher works ? I don’t understand why the progress indicator hack is even necessary – call me naïve. I would have thought that for any given widget, the AJAX listening to UIDL could just have been in slow-load mode, such that whenever the server updated the component based on a repaint or other event, the client would immediately know. What am I missing?

To be truthful, I’m not entirely sure what the technical reasons to the requirement of this kind of a component, either. That’s something the DEV team could explain.

But my guess is that Vaadin assumes that for each change in the server side, you have first triggered an event in the client side (say, pushed a Button). During this roundtrip, the server side changes its state, and returns the required changes for the client as an UIDL. Now, in a self-contained, long-lived thread, you may have server-side changes that aren’t triggered by the client side (say, percentage complete of a calculation, a typical use for the Progress Indicator). Because Vaadin (or, HTTP, rather) lacks server-side push, you need a component to actively poll for server-side changes at an interval.

Because the Progress Indicator was the only component that had any kind of polling mechanism built in, users were forced to use the PI even if they wanted to listen to autonomous server-side changes. Because the PI is a visual component, if you only want a poller, you needed to try to hide the visual representation by various CSS tricks. The Refresher, on the other hand, has no visual representation, it’s only a component that repeatedly asks the server whether any changes has happened.

Technically, the Refresher is a Progress Indicator without the progress bar :slight_smile:

Hope that cleared up things a bit (without being factually incorrect. DEV?)

Nice work. Small is beautiful.

The window manager pattern actually feels very useful. Animation effects for the minimize/maximize, maybe? :slight_smile:

The current “progress-bar enables polling solution” is not a proper way to do it. Basically this says - there is no polling, implement it in your widget if you need it.

For a while I have dreamed of the following API, but have not had time to do anything about it yet:
Window.setUpdateFrequency(int x)
If x == 0, no automatic updates are done (current default)
If x > 0, window would poll automatically once per x milliseconds
If x == SERVER_PUSH == -1, serversize push mechanism (implemented with Kaazing?) would be enabled for this window.

Thank you for these components, Henrik!
They should probably be included in some released components.jar together with Vaadin.

In the meanwhile, I tried to integreate them in my project, but I’m very novice with GWT and Vaadin client side components and I’ve some troubles. Hope you can help me :slight_smile:

I’ve done the following steps:

  • copied the source code com.vaadin.contrib.hcomponents in my project source folder.
  • I added gwt-dev-windows.jar and gwt-user.jar (v1.6.4) to my Java build path.
  • I created a launch configuration to compile the GWT code (through another test project, where I used the plugin to create a fake widgetset to have the .launch file).
  • I made that GWT compilation run sucessfully
  • It created a sub directory in WebContent/VAADIN/widgetsets/ which name is com.vaadin.contrib.hcomponents.ComponentsApplicationWidgetset, with a few files (probably GWT files). There is also another sub directory: com.vaadin.terminal.gwt.DefaultWidgetSet

I use vaadin-6.1.0-pre2.jar

So far so good?
I change my application to include the Refresher in a VerticalLayout.
I run the application, but the RefresherListener is not called and in the browser, I can read:

Client faced an unknown component type. Unrendered UIDL:

inside the containing VerticalLayout.

I guess I missed something trivial.

Does anybody have an idea for me?

Many thanks.

Unfortunately, I haven’t reviewed the components in a long while, and they are definitely not updated for Vaadin 6.1. That said, You mentioned that you used GWT 1.6. That might one problem - Vaadin 6.1 requires GWT 1.7 now.

Check out and the heading “Server-side Upgrade Instructions” for more info.

I can’t help you more than this off the bat. I hope that if someone notices other errors, he/she would point those out. But I really should take a re-check with these components and try to make them work on Vaadin 6.1. I’ll chime back in once I get that far.

Oh btw, I assume that you have read the chapter in the manual about custom widgetsets:

Now, reading more carefully, you didn’t mention that you edited some crucial files. You need to edit your web.xml-file and define there which widgetset you are using. Assuming that you are using only and exclusively the HComponents widgetset, you just define “com.vaadin.contrib.hcomponents.client.ComponentsApplicationWidgetset” as the entry point.

Thank you for the hint, Henrik. I just updated to GWT 1.7, but problem remains.

I don’t think there is anything wrong with your code. I believe it’s more a configuration problem due to my inexperience with GWT. It’s like if the wrong widgetset factory is called and that factory does not recognize the refresher tag.

You are right, I missed that part.
It works, thank you very much!

Happy to help!

Now I start having questions on the components themselves, Henrik. Probably more interesting.

I’m trying the SuperImmediateTextField.

On the server side, SuperImmediateTextField extends TextField, which makes it possible to call .setRows(15).
In the browser, it display only one row, probably an input instead of a textarea.

My guess was that on the client side, VSuperImmediateTextField extends VTextField and that VTextField is an input.
So I changed the code and made VSuperImmediateTextField extends VTextArea, and it works.

Is there a reason why you did exted VTextField instead of VTextArea?

In the, I see:

        } else if ("textfield".equals(tag)) {
            if (uidl.getBooleanAttribute("richtext")) {
                return VRichTextArea.class;
            } else if (uidl.hasAttribute("multiline")) {
                return VTextArea.class;
            } else if (uidl.getBooleanAttribute("secret")) {
                return VPasswordField.class;
            } else {
                return VTextField.class;

Would this mean that we should create have one VSuperImmediateXxxxField/ class per possible widget?


The main reason to this is basically laziness. I’m, after all, a total newbie with GWT, and adding support for all the various TextField types seemed non-trivial (i.e. required more than a moment’s thought), so I didn’t bother.

In a nutshell: it’s an honest to deity hack.

If you happen to have the time and energy to make it work properly, I’m more than happy to accept patches. If you are able to commit to the contrib repository (I’m not really sure how the restrictions work), feel free to update the code directly in the repository, provided sufficient testing etc.

It would seem so, yes. Mixins or delegate objects would be pretty awesome right now :slight_smile:

Someone knows if there is a plan to add the SuperImmediateTextField functionality to the standard Vaadin TextField in the future?


I found this ticket
, that does mention something about superimmediateness. But it’s in the backlog, opened over a year ago, and last touched at half a year ago. So, I’d parse that as “yeah, sure, we could have this. Some day, but not in a while.”

Ok then, I will try to request this addition.

For now I’m using your code, thank you very much!!! The only “problem” I have found is that when you reload the page in the browser, if you had some text in the SuperImmediateTextField the text is lost. Do you know what could be the reason of that?

Thanks again Henrik.

The textfield’s internal value isn’t set (i.e. sitf.setValue(event.getSource().getText()) ) when the KeyPressEvent is sent, and I’m not really sure whether it should be set, either. But I just noticed that the SITF isn’t in “normal” immediate mode by default (i.e. value is sent to the server when focus is lost), and I guess that should be changed to be immediate by default.