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

Integrating with the Server-Side

});

}

}

In addition, all Vaadin components get the v-widget class. If it extends an existing Vaadin or GWT widget, it will inherit CSS classes from that as well.

16.8.2. Default Stylesheet

A client-side module, which is normally a widget set, can include stylesheets. They must be placed under the public folder under the folder of the widget set, a described in Section 13.3.1, “Specifying a Stylesheet”.

For example, you could style the widget described above as follows:

.mypicker { white-space: nowrap;

}

.mypicker-button { display: inline-block; border: 1px solid black; padding: 3px;

width: 15px; text-align: center;

}

Notice that some size settings may require more complex handling and calculating the sizes dynamically.

16.9. Component Containers

Component containers, such as layout components, are a special group of components that require some consideration. In addition to handling state, they need to manage communicating the hierarchy of their contained components to the other side.

The easiest way to implement a component container is extend the AbstractComponentContainer, which handles the synchronization of the container server-side components to the clientside.

16.10. Creating Add-ons

Add-ons are the most convenient way to reuse Vaadin code, either commercially or free. Vaadin Directory serves as the store for the add-ons. You can distribute add-ons both as JAR libraries and Zip packages.

Creating a typical add-on package involves the following tasks:

•Compile server-side classes

•Compile JavaDoc (optional)

•Build the JAR

•Include Vaadin add-on manifest

•Include the compiled server-side classes

Integrating with the Server-Side

•Include the compiled JavaDoc (optional)

•Include sources of client-side classes for widget set compilation (optional)

•Include any JavaScript dependency libraries (optional)

•Exclude any test or demo code in the project

The exact contents depend on the add-on type. Component add-ons often include a widget set, but also JavaScript components and pure server-side components are possible, which do not have a widget set. You can also have data container add-ons and theme add-ons, which do not have a widget set, as well as various tools.

It is common to distribute the JavaDoc in a separate JAR, but you can also include it in the same JAR.

16.10.1. Exporting Add-on in Eclipse

If you use the Vaadin Plugin for Eclipse for your add-on project, you can simply export the addon from Eclipse.

3.In the Select the resources to export panel, select the content that should be included in the add-on package. In general, you should include sources in src folder (at least for the client-side package), compiled server-side classes, themes in WebContent/VAADIN/themes. These are all included automatically. You probably want to leave out any demo or example code.

If you are submitting the add-on to Vaadin Directory, the Implementation title should be exactly the name of the add-on in Directory.The name may contain spaces and most other letters. Notice that it is not possible to change the name later.

The Implementation version is the version of your add-on. Typically experimental or beta releases start from 0.1.0, and stable releases from 1.0.0.

The Widgetsets field should list the widget sets included in the add-on, separated by commas. The widget sets should be listed by their class name, that is, without the

.gwt.xml extension.

The JAR file is the file name of the exported JAR file. It should normally include the version number of the add-on. You should follow the Maven format for the name, such as myaddon-1.0.0.jar.

Finally, click Finish.

16.10.2.Building Add-on with Ant

Building an add-on with Ant is similar to building Vaadin applications. Vaadin libraries and other dependencies are retrieved and included in the classpath using Apache Ivy.

In the following, we assume the Eclipse project structure. Let us put the build script in the build folder under the project. We begin the Ant script as follows:

Integrating with the Server-Side

Figure 16.4. Exporting a Vaadin Add-on

<?xml version="1.0"?>

<project xmlns:ivy="antlib:org.apache.ivy.ant" name="My Own add-on"

Integrating with the Server-Side

basedir=".." default="package-jar">

The namespace declaration is all you need to do to enable Ivy in Ant 1.6 and later. For earlier Ant versions, please see the Ivy documentation.

Configuration and Initialization

In the example script, we organize most settings in a configure target and then initialize the build in init target.

<target name="configure">

<!-- Where project source files are located --> <property name="src-location" value="src" />

<!-- Name of the widget set. -->

<property name="widgetset" value="com.example.myaddon.widgetset.MyAddonWidgetset"/>

<!-- Addon version -->

<property name="version" value="0.1.0"/>

<!-- Compilation result directory -->

<property name="result-dir" value="build/result"/>

<!-- The target name of the built add-on JAR --> <property name="target-jar"

value="${result-dir}/myaddon-${version}.jar"/> </target>

<target name="init" depends="configure"> <!-- Construct and check classpath --> <path id="compile.classpath">

<pathelement path="build/classes" /> <pathelement path="${src-location}" /> <fileset dir="${result-dir}/lib">

<include name="*.jar"/> </fileset>

</path>

<mkdir dir="${result-dir}"/> </target>

You will need to make some configuration also in the package-jar target in addition to the configure target.

Compiling the Server-Side

Compiling the add-on requires the Vaadin libraries and any dependencies. We use Apache Ivy for resolving the dependencies and retrieving the library JARs.

<!-- Retrieve dependencies with Ivy --> <target name="resolve" depends="init">

<ivy:retrieve pattern="${result-dir}/lib/[artifact].[ext]"/>

</target>

The pattern attribute for the <retrieve> task specifies where the dependencies are stored, in the above case in the build/result/lib directory.

Compiling the server-side classes is then straight-forward:

Integrating with the Server-Side

<!-- Compile server-side --> <target name="compile-server-side"

depends="init, resolve">

<delete dir="${result-dir}/classes"/> <mkdir dir="${result-dir}/classes"/>

<javac srcdir="${src-location}" destdir="${result-dir}/classes">

<classpath>

<path refid="compile.classpath"/> </classpath>

</javac>

</target>

Compiling the JavaDoc

You may want to include API documentation for the add-on in the same or in a different JAR file. You can do it as follows, using the configuration we defined earlier. You may want to exclude the client-side classes and any test and demo classes from the JavaDoc, as is done in this example, if they are in the same source tree.

<!-- Compile JavaDoc -->

<target name="compile-javadoc" depends="init"> <delete dir="${result-dir}/javadoc"/> <mkdir dir="${result-dir}/javadoc"/>

<javadoc destdir="${result-dir}/javadoc"> <sourcefiles>

<fileset dir="${src-location}" id="src"> <include name="**/*.java"/>

<!-- Excluded stuff from the package --> <exclude name="**/client/**/*"/> <exclude name="**/demo/**/*"/>

<exclude name="**/MyDemoUI.java"/> </fileset>

</sourcefiles>

<classpath>

<path refid="compile.classpath"/> </classpath>

</javadoc>

</target>

Packaging the JAR

An add-on JAR typically includes the following:

•Vaadin add-on manifest

•The compiled server-side classes

•The compiled JavaDoc (optional)

•Sources of client-side classes (optional)

•Any JavaScript dependency libraries (optional)

Let us begin crafting the target. The JAR requires the compiled server-side classes and the optional API documentation.

<target name="package-jar"