Файл: book-of-vaadin.pdf

Advanced Web Application Topics

ordinates relative to the wrapper. Notice that the coordinates are really the position of the wrapper, not the wrapped component; the wrapper reserves some space for the accept indicators.

The verticalDropLocation() and horizontalDropLocation() return the more detailed drop location in the target.

11.11.7. Dragging Files from Outside the Browser

The DragAndDropWrapper allows dragging files from outside the browser and dropping them on a component wrapped in the wrapper. Dropped files are automatically uploaded to the application and can be acquired from the wrapper with getFiles(). The files are represented as Html5File objects as defined in the inner class. You can define an upload Receiver to receive the content of a file to an OutputStream.

Dragging and dropping files to browser is supported in HTML 5 and requires a compatible browser, such as Mozilla Firefox 3.6 or newer.

11.12. Logging

You can do logging in Vaadin application using the standard java.util.logging facilities. Configuring logging is as easy as putting a file named logging.properties in the default package of your Vaadin application (src in an Eclipse project or src/main/java or src/main/resources in a Maven project). This file is read by the Logger class when a new instance of it is initialize.

Logging in Apache Tomcat

For logging Vaadin applications deployed in Apache Tomcat, you do not need to do anything special to log to the same place as Tomcat itself. If you need to write the Vaadin application related messages elsewhere, just add a custom logging.properties file to the default package of your Vaadin application.

If you would like to pipe the log messages through another logging solution, see the section called “Piping to Log4j using SLF4J” below.

Logging in Liferay

Liferay mutes logging through java.util.logging by default. In order to enable logging, you need to add a logging.properties file of your own to the default package of your Vaadin application. This file should define at least one destination where to save the log messages.

You can also log through SLF4J, which is used in and bundled with Liferay. Follow the instructions in the section called “Piping to Log4j using SLF4J”.

Piping to Log4j using SLF4J

Piping output from java.util.logging to Log4j is easy with SLF4J (http://slf4j.org/). The basic way to go about this is to add the SLF4J JAR file as well as the jul-to-slf4j.jar file, which implements the bridge from java.util.logging, to SLF4J. You will also need to add a third logging implementation JAR file, that is, slf4j-log4j12-x.x.x.jar, to log the actual messages using Log4j. For more info on this, please visit the SLF4J site.

In order to get the java.util.logging to SLF4J bridge installed, you need to add the following snippet of code to your Application class at the very top:

Advanced Web Application Topics

static { SLF4JBridgeHandler.install();

}

This will make sure that the bridge handler is installed and working before Vaadin starts to process any logging calls.

Please note!

This can seriously impact on the cost of disabled logging statements (60-fold increase) and a measurable impact on enabled log statements (20% overall increase). However, Vaadin doesn't log very much, so the effect on performance will be negligible.

Using Logger

You can do logging with a simple pattern where you register a static logger instance in each class that needs logging, and use this logger wherever logging is needed in the class. For example:

public class MyClass {

private final static Logger logger = Logger.getLogger(MyClass.class.getName());

public void myMethod() { try {

// do something that might fail

}catch (Exception e) {

logger.log(Level.SEVERE, "FAILED CATASTROPHICALLY!", e);

}

}

}

Having a static logger instance for each class needing logging saves a bit of memory and time compared to having a logger for every logging class instance. However, it could cause the application to leak PermGen memory with some application servers when redeploying the application. The problem is that the Logger may maintain hard references to its instances. As the Logger class is loaded with a classloader shared between different web applications, references to classes loaded with a per-application classloader would prevent garbage-collecting the classes after redeploying, hence leaking memory. As the size of the PermGen memory where class object are stored is fixed, the leakage will lead to a server crash after many redeployments. The issue depends on the way how the server manages classloaders, on the hardness of the back-refer- ences, and may also be different between Java 6 and 7. So, if you experience PermGen issues, or want to play it on the safe side, you should consider using non-static Logger instances.

11.13. JavaScript Interaction

Vaadin supports two-direction JavaScript calls from and to the server-side.This allows interfacing with JavaScript code without writing client-side integration code.

11.13.1. Calling JavaScript

You can make JavaScript calls from the server-side with the execute() method in the JavaScript class.You can get a JavaScript instance from the current Page object with getJavaScript().

// Execute JavaScript in the currently processed page Page.getCurrent().getJavaScript().execute("alert('Hello')");

Advanced Web Application Topics

The JavaScript class itself has a static shorthand method getCurrent() to get the instance for the currently processed page.

// Shorthand JavaScript.getCurrent().execute("alert('Hello')");

The JavaScript is executed after the server request that is currently processed returns. If multiple JavaScript calls are made during the processing of the request, they are all executed sequentially after the request is done. Hence, the JavaScript execution does not pause the execution of the server-side application and you can not return values from the JavaScript.

11.13.2. Handling JavaScript Function Callbacks

You can make calls with JavaScript from the client-side to the server-side. This requires that you register JavaScript call-back methods from the server-side. You need to implement and register a JavaScriptFunction with addFunction() in the current JavaScript object. A function requires a name, with an optional package path, which are given to the addFunction(). You only need to implement the call() method to handle calls from the client-side JavaScript.

JavaScript.getCurrent().addFunction("com.example.foo.myfunc", new JavaScriptFunction() {

@Override

public void call(JSONArray arguments) throws JSONException { Notification.show("Received call");

}

});

Link link = new Link("Send Message", new ExternalResource( "javascript:com.example.foo.myfunc()"));

Parameters passed to the JavaScript method on the client-side are provided in a JSONArray passed to the call() method. The parameter values can be acquired with the get() method by the index of the parameter, or any of the type-casting getters. The getter must match the type of the passed parameter, or a JSONException is thrown.

JavaScript.getCurrent().addCallback("com.example.foo.myfunc",

new JavaScriptCallback() {

});

Link link = new Link("Send Message", new ExternalResource( "javascript:com.example.foo.myfunc(prompt('Message'), 42)"));

The callback mechanism is the same as the RPC mechanism used with JavaScript component integration, as described in Section 16.12.4, “RPC from JavaScript to Server-Side”.