Problem with embedded jsp-page links


I have trouble understanding how to get links within embedded jsp-pages to work. I set up a simple panel, label and an embedded jsp-page with the following code:

public class TestApplication extends Application {
    public void init() {
        Window window = new Window();
        window.addURIHandler(new TestUriHandler());
    public class TestUriHandler  implements URIHandler {
        public DownloadStream handleURI(URL context, String relativeUri) {
            Panel testPanel = new Panel();
            testPanel.addComponent(new Label("test"));
            testPanel.addComponent(new TestEmbedded());
            return null;
    public class TestEmbedded extends Embedded
        public TestEmbedded()
            setSource(new ExternalResource("testView.jsp"));

This results in a view presented in this

When I click the link, I would expect my browser window contents to be set to a new testPanel. However, I get a new window overlapping the old. This happens every time I click the link, as shown by this
. Clicking Buttons or other active Components in the not-latest window naturally results in an out-of-sync error.

Can anyone point out what I’m doing wrong? I would really need to embed some jsp in our project.

What happens is very clear when you look at the DOM structure. You embed testView.jsp in an iframe, and in jsp I guess you have a link to the application. Clicking the link will when open the application, INSIDE the iframe. Now you have the same application embedded inside itself, and it surely won’t work to click components outside the iframe as they only exist on your browser page (until refreshed) and not on the server. A workaround might be to open the link in the “_top” window, depending on what you want to accomplish.

By the way, that’s some serious misuse of an URIHandler and probably won’t work e.g. in Google App Engine. I think a transactionListener would be more appropriate.


I wasn’t able to dig out from the source code that I was dealing with an iframe. I can get the functionality I need by targeting _top with my link, like you said.

Regarding the URIHandler, this was just a quick example code, but we do use a somewhat similar approach in our app. I would appreciate any tips if we’re doing this wrong.

In our URIHandler we have a single method refreshMainView() which checks the state of the app and sets the content of the window accordingly. If the state hasn’t changed since the last call, we can naturally skip content setting. The purpose of this is mainly to redirect the user to a login page if they’re logged out. Does this functionality belong somewhere else?

Using an URIHandler which does not check the URI kinda defeats the purpose of an URIHandler. A transactionListener might be more appropriate in this case.

If you want to handle logouts there are also methods for this in the framework. If your default application shows the login screen, you can just do application.close() if the user has been logged out. This will close the current application and create a new one for the user. The new one will then obviously show the login screen as this is the first screen in the application.

If you have multiple views that the user can switch between it can be advantegous (and clearer) to use multiple windows instead of custom URIHandling. The only case I can think of right now where URIHandling is absolutely the way to go is when serving (dynamically generated) downloadable resources.