summaryrefslogtreecommitdiffstats
path: root/documentation/clientside/clientside-module.asciidoc
blob: 4656264ce165285e48b4fbee8a8c2538cdc6bb12 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
---
title: Client-Side Module Descriptor
order: 3
layout: page
---

[[clientside.module]]
= Client-Side Module Descriptor

Client-side Vaadin modules, such as the Vaadin Client-Side Engine (widget set)
or pure client-side applications, that are to be compiled to JavaScript, are
defined in a __module descriptor__ ( [filename]#.gwt.xml#) file.

When defining a widget set to build the Vaadin client-side engine, the only
necessary task is to inherit a base widget set. If you are developing a regular
widget set, you should normally inherit the [classname]#DefaultWidgetSet#.


----

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC
  "-//Google Inc.//DTD Google Web Toolkit 1.7.0//EN"
  "http://google-web-toolkit.googlecode.com/svn/tags/1.7.0/distro-source/core/src/gwt-module.dtd">

<module>
    <!-- Inherit the default widget set -->
    <inherits name="com.vaadin.DefaultWidgetSet" />
</module>
----

If you are developing a pure client-side application, you should instead inherit
[classname]#com.vaadin.Vaadin#, as described in
<<dummy/../../../framework/clientsideapp/clientsideapp-overview.asciidoc#clientsideapp.overview,"Client-Side
Applications">>. In that case, the module descriptor also needs an entry-point.

If you are using the Eclipse IDE, the New Vaadin Widget wizard will
automatically create the GWT module descriptor. See
<<dummy/../../../framework/gwt/gwt-eclipse#gwt.eclipse.widget,"Creating a
Widget">> for detailed instructions.

[[clientside.module.stylesheet]]
== Specifying a Stylesheet

A client-side module can include CSS stylesheets. When the module is compiled,
these stylesheets are copied to the output target. In the module descriptor,
define a [literal]#++stylesheet++# element.

For example, if you are developing a custom widget and want to have a default
stylesheet for it, you could define it as follows:


----
<stylesheet src="mywidget/styles.css"/>
----

The specified path is relative to the __public__ folder under the folder of the
module descriptor.


[[gwt.module.compilation-limiting]]
== Limiting Compilation Targets

Compiling widget sets takes considerable time. You can reduce the compilation
time significantly by compiling the widget sets only for your browser, which is
useful during development. You can do this by setting the
[parameter]#user.agent# property in the module descriptor.


----
<set-property name="user.agent" value="gecko1_8"/>
----

The [parameter]#value# attribute should match your browser. The browsers
supported by GWT depend on the GWT version, below is a list of browser
identifiers supported by GWT.

.GWT User Agents
[options="header"]
|===============
|Identifier|Name
|ie6|Internet Explorer 6
|ie8|Internet Explorer 8
|gecko1_8|Mozilla Firefox 1.5 and later
|safari|Apple Safari and other Webkit-based browsers including Google Chrome
|opera|Opera
|ie9|Internet Explorer 9

|===============




For more information about the GWT Module XML Format, please see Google Web
Toolkit Developer Guide.
ass="w"> discussion focusses on the relationship between Flow Objects in the Flow Object tree, and properties. There is no (or only passing) discussion of the relationship between properties and traits, and by extension, between properties and the Area tree. The discussion is illustrated with some pseudo-UML diagrams. </note> <p> Property handling is complex and expensive. Varying numbers of properties apply to individual Flow Objects <strong>(FOs)</strong> in the <strong>FO tree </strong> but any property may effectively be assigned a value on any element of the tree. If that property is inheritable, its defined value will then be available to any children of the defining FO. </p> <note> <em>(XSL 1.0 Rec)</em> <strong>5.1.4 Inheritance</strong> ...The inheritable properties can be placed on any formatting object. </note> <p> Even if the value is not inheritable, it may be accessed by its children through the <code>inherit</code> keyword or the <code>from-parent()</code> core function, and potentially by any of its descendents through the <code>from-nearest-specified-value()</code> core function. </p> <p> In addition to the assigned values of properties, almost every property has an <strong>initial value</strong> which is used when no value has been assigned. </p> <s2 title="The history problem"> <p> The difficulty and expense of handling properties comes from this univeral inheritance possibility. The list of properties which are assigned values on any particular <em>FO</em> element will not generally be large, but a current value is required for each property which applies to the <em>FO</em> being processed. </p> <p> The environment from which these values may be selected includes, for each <em>FO</em>, for each applicable property, the value assigned on this <em>FO</em>, the value which applied to the parent of this <em>FO</em>, the nearest value specified on an ancestor of this element, and the initial value of the property. </p> </s2> <s2 title="Data requirement and structure"> <p> This determines the minimum set of properties and associated property value assignments that is necessary for the processing of any individual <em>FO</em>. Implicit in this set is the set of properties and associated values, effective on the current <em>FO</em>, that were assigned on that <em>FO</em>. </p> <p> This minimum requirement - the initial value, the nearest ancestor specified value, the parent computed value and the value assigned to the current element - suggests a stack implementation. </p> </s2> <s2 title="Stack considerations"> <p> One possibility is to push to the stack only a minimal set of required elements. When a value is assigned, the relevant form or forms of that value (specified, computed, actual) are pushed onto the stack. As long as each <em>FO</em> maintains a list of the properties which were assigned from it, the value can be popped when the focus of FO processing retreats back up the <em>FO</em> tree. </p> <p> The complication is that, for elements which are not automatically inherited, when an <em>FO</em> is encountered which does <strong>not</strong> assign a value to the property, the initial value must either be already at the top of the stack or be pushed onto the stack. </p> <p> As a first approach, the simplest procedure may be to push a current value onto the stack for every element - initial values for non-inherited properties and the parental value otherwise. Then perform any processing of assigned values. This simplifies program logic at what is hopefully a small cost in memory and processing time. It may be tuned in a later iteration. </p> <s3 title="Stack implementation"> <p> Initial attempts at this implementation have used <code>LinkedList</code>s as the stacks, on the assumption that </p> <sl> <!-- one of (dl sl ul ol li) --> <li>random access would not be required</li> <li> pushing and popping of list elements requires nearly constant (low) time </li> <li> no penalty for first addition to an empty list</li> <li>efficient access to both bottom and top of stack</li> </sl> <p> However, it may be required to perform stack access operations from an arbitrary place on the stack, in which case it would probably be more efficient to use <code>ArrayList</code>s instead. </p> </s3> </s2> <s2 title="Class vs instance"> <p> An individual stack would contain values for a particular property, and the context of the stack is the property class as a whole. The property instances would be represented by the individual values on the stack. If properties are to be represented as instantiations of the class, the stack entries would presumably be references to, or at least referenced from, individual property objects. However, the most important information about individual property instances is the value assigned, and the relationship of this property object to its ancestors and its descendents. Other information would include the ownership of a property instance by a particular <em>FO</em>, and, in the other direction, the membership of the property in the set of properties for which an <em>FO</em> has defined values. </p> <p> In the presence of a stack, however, none of this required information mandates the instantiation of properties. All of the information mentioned so far can be effectively represented by a stack position and a link to an <em>FO</em>. If the property stack is maintained in parallel with a stack of <em>FOs</em>, even that link is implicit in the stack position. </p> </s2> <p> <strong>Next:</strong> <link href= "classes-overview.html" >property classes overview.</link> </p> </s1> </body> </document>