Advanced Web Application Topics

11.2.3. Cross-Site Embedding with the Vaadin XS Add-on

In the previous sections, we described the two basic methods for embedding Vaadin applications: in a <div> element and in an <iframe>. One problem with div embedding is that it does not work between different Internet domains, which is a problem if you want to have your website running in one server and your Vaadin application in another. The security model in browsers effectively prevents such cross-site embedding of Ajax applications by enforcing the same origin policy for XmlHttpRequest calls, even if the server is running in the same domain but different port. While iframe is more permissive, allowing embedding almost anything in anywhere, it has many disadvantanges, as described earlier.

The Vaadin XS (Cross-Site) add-on works around the limitation in div embedding by using JSONPstyle communication instead of the standard XmlHttpRequests.

Embedding is done simply with:

<script src="http://demo.vaadin.com/xsembed/getEmbedJs" type="text/javascript"></script>

This includes an automatically generated embedding script in the page, thereby making embedding effortless.

This assumes that the main layout of the application has undefined height. If the height is 100%, you have to wrap it inside an element with a defined height. For example:

<div style="height: 500px;">

<script src="http://demo.vaadin.com/xsembed/getEmbedJs" type="text/javascript"></script>

</div>

It is possible to restrict where the application can be embedded by using a whitelist. The add-on also encrypts the client-server communication, which is more important for embedded applications than usual.

You can get the Vaadin XS add-on from Vaadin Directory. It is provided as a Zip package. Download and extract the installation package to a local folder. Instructions for installation and further information is given in the README.html file in the package.

Some restrictions apply. You can have only one embedded application in one page. Also, some third-party libraries may interfere with the communication. Other notes are given in the README.

11.3. Debug and Production Mode

Vaadin applications can be run in two modes: debug mode and production mode. The debug mode, which is on by default, enables a number of built-in debug features for the developers. The features include:

•Debug Window for accessing debug functionalities

•Display debug information in the Debug Window and server console.

•Analyze layouting button that analyzes the layout for possible problems.

All applications are run in the debug mode by default (since IT Mill Toolkit version 5.3.0). The production mode can be enabled, and debug mode thereby disabled, by adding a productionMode=true parameter to the servlet context in the web.xml deployment descriptor:

Cross-Site Embedding with the Vaadin XS Add-on

287

Advanced Web Application Topics

<context-param>

<description>Vaadin production mode</description> <param-name>productionMode</param-name> <param-value>true</param-value>

</context-param>

Enabling the production mode disables the debug features, thereby preventing users from easily inspecting the inner workings of the application from the browser.

11.3.1. Debug Mode

Running an application in the debug mode enables the client-side Debug Window in the browser. You can open the Debug Window by adding "?debug" to the application URL, for example, http://localhost:8080/myapp/?debug. The Debug Window has buttons for controlling the debugging features and a scrollable log of debug messages.

The debug window has many more features than documented here and will be redesigned in Vaadin 7.1 after publication of this print edition. Please refer to updated documentation published at a later time.

If you use the Firebug plugin for Firefox or the Developer Tools console in Chrome, the log messages will also be printed to the Firebug console. In such a case, you may want to enable client-side debugging without showing the Debug Window with "?debug=quiet" in the URL. In the quiet debug mode, log messages will only be printed to the console of the browser debugger.

11.3.2. Analyzing Layouts

The Analyze layouts button analyzes the currently visible layouts and makes a report of possible layout related problems. All detected layout problems are displayed in the log and also printed to the console.

The most common layout problem is caused by placing a component that has a relative size inside a container (layout) that has undefined size, for example, adding a 100% wide Panel inside a HorizontalLayout with no width specification. In such a case, the error will look as shown below:

Vaadin DEBUG

-Window/1a8bd74 "My window" (width: MAIN WINDOW) - HorizontalLayout/1cf243b (width: UNDEFINED)

- Panel/12e43f1 "My panel" (width: RELATIVE, 100.0 %)

Layout problem detected: Component with relative width inside a HorizontalLayout with no width defined

Relative sizes were replaced by undefined sizes, components may not render as expected.

This particular error tells that the Panel "My panel" is 100% wide while the width of the containing HorizontalLayout is undefined. The components will be rendered as if the the width of the contained Panel was undefined, which might not be what the developer wanted. There are two possible fixes for this case: if the Panel should fill the main window horizontally, set a width for the HorizontalLayout (for example 100% wide), or set the width of the Panel to "undefined" to render the it as it is currently rendered but avoiding the warning message.

The same error is shown in the Debug Window in a slightly different form and with an additional feature (see Figure 11.3, “Debug Window Showing the Result of Analyze layouts.”). Checking the Emphasize component in UI box will turn red the background of the component that caused a warning, making it easy for the developer to figure out which component each warning relates to.The messages will also be displayed hierarchically, as a warning from a containing component

288	Debug Mode