mirrors
/
vaadin-framework
mirror of https://github.com/vaadin/framework.git
Watch 1
Star 0
Fork 0
Code Issues 0 Releases 328 Wiki Activity
Browse Source

Add missing [source, java] to the java code blocks in documentation (#11381) 

* Update clientsideapp-entrypoint.asciidoc

Adding missing ```[source, java]```
tags/8.7.0.beta1
Anastasia Smirnova 5 years ago
parent
ccb1c45a6a
commit
febddda057
11 changed files with 31 additions and 31 deletions
Split View Show Diff Stats
  1. 2
    2
      documentation/clientsideapp/clientsideapp-entrypoint.asciidoc
  2. 1
    1
      documentation/clientsideapp/clientsideapp-loading.asciidoc
  3. 1
    1
      documentation/clientsideapp/clientsideapp-overview.asciidoc
  4. 3
    3
      documentation/clientsidewidgets/clientsidewidgets-grid.asciidoc
  5. 1
    1
      documentation/clientsidewidgets/clientsidewidgets-vaadin.asciidoc
  6. 1
    1
      documentation/gwt/gwt-connector.asciidoc
  7. 3
    3
      documentation/gwt/gwt-extension.asciidoc
  8. 3
    3
      documentation/gwt/gwt-rpc.asciidoc
  9. 1
    1
      documentation/gwt/gwt-server-side.asciidoc
  10. 14
    14
      documentation/gwt/gwt-shared-state.asciidoc
  11. 1
    1
      documentation/gwt/gwt-styling.asciidoc

+ 2
- 2
documentation/clientsideapp/clientsideapp-entrypoint.asciidoc View File

@@ -12,7 +12,7 @@ starts, much like the [methodname]#init()# method in server-side Vaadin UIs.

Consider the following application:

[source, java]
----
package com.example.myapp.client;

@@ -51,7 +51,7 @@ configuration, in a client-side module descriptor, described in
Module Descriptor">>. The descriptor is an XML file with suffix
[filename]#.gwt.xml#.

[source, xml]
----
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC

+ 1
- 1
documentation/clientsideapp/clientsideapp-loading.asciidoc View File

@@ -11,7 +11,7 @@ You can load the JavaScript code of a client-side application in an HTML __host
page__ by including it with a [literal]#++<script>++# tag, for example as
follows:

[source, html]
----
<html xmlns="http://www.w3.org/1999/xhtml">
<head>

+ 1
- 1
documentation/clientsideapp/clientsideapp-overview.asciidoc View File

@@ -30,7 +30,7 @@ the JavaScript of the compiled module is loaded in the browser.

Consider the following client-side application:

[source, java]
----
public class HelloWorld implements EntryPoint {
@Override

+ 3
- 3
documentation/clientsidewidgets/clientsidewidgets-grid.asciidoc View File

@@ -29,7 +29,7 @@ modify the element as needed.

For example, [classname]#TextRenderer# is implemented simply as follows:

[source, java]
----
public class TextRenderer implements Renderer<String> {
@Override
@@ -44,7 +44,7 @@ The server-side renderer API should extend [classname]#AbstractRenderer# or
[classname]#ClickableRenderer# with the data type accepted by the renderer. The
data type also must be given for the superclass constructor.

[source, java]
----
public class TextRenderer extends AbstractRenderer<String> {
public TextRenderer() {
@@ -56,7 +56,7 @@ public class TextRenderer extends AbstractRenderer<String> {
The client-side and server-side renderer need to be connected with a connector
extending from [classname]#AbstractRendererConnector#.

[source, java]
----
@Connect(com.vaadin.ui.renderer.TextRenderer.class)
public class TextRendererConnector

+ 1
- 1
documentation/clientsidewidgets/clientsidewidgets-vaadin.asciidoc View File

@@ -13,7 +13,7 @@ widgets have somewhat different feature set from the GWT widgets and are
foremost intended for integration with the server-side components, but some may
prove useful for client-side applications as well.

[source, java]
----
public class MyEntryPoint implements EntryPoint {
@Override

+ 1
- 1
documentation/gwt/gwt-connector.asciidoc View File

@@ -23,7 +23,7 @@ The basic tasks of a connector is to hook up to the widget and handle events
from user interaction and changes received from the server. A connector also has
a number of routine infrastructure methods which need to be implemented.

[source,java]
----
@Connect(MyComponent.class)
public class MyComponentConnector

+ 3
- 3
documentation/gwt/gwt-extension.asciidoc View File

@@ -34,7 +34,7 @@ extended component or UI as a parameter and passes it to __super.extend()__.
For example, let us have a trivial example with an extension that takes no
special parameters, and illustrates the three alternative APIs:

[source,java]
----
public class CapsLockWarning extends AbstractExtension {
// You could pass it in the constructor
@@ -56,7 +56,7 @@ public class CapsLockWarning extends AbstractExtension {

The extension could then be added to a component as follows:

[source,java]
----
PasswordField password = new PasswordField("Give it");

@@ -96,7 +96,7 @@ In the following example, we implement a "Caps Lock warning" extension. It
listens for changes in Caps Lock state and displays a floating warning element
over the extended component if the Caps Lock is on.

[source,java]
----
@Connect(CapsLockWarning.class)
public class CapsLockWarningConnector

+ 3
- 3
documentation/gwt/gwt-rpc.asciidoc View File

@@ -28,7 +28,7 @@ interface simply defines any methods that can be called through the interface.

For example:

[source,java]
----
public interface MyComponentServerRpc extends ServerRpc {
public void clicked(String buttonName);
@@ -54,7 +54,7 @@ Before making a call, you need to instantiate the server RPC object with
[methodname]#RpcProxy.create()#. This is usually done transparently by using [methodname]#getRpcProxy()#. After that, you can make calls through the
server RPC interface that you defined, for example as follows:

[source,java]
----
@Connect(MyComponent.class)
public class MyComponentConnector
@@ -87,7 +87,7 @@ RPC calls are handled in a server-side implementation of the server RPC
interface. The call and its parameters are serialized and passed to the server
in an RPC request transparently.

[source,java]
----
public class MyComponent extends AbstractComponent {
private MyComponentServerRpc rpc =

+ 1
- 1
documentation/gwt/gwt-server-side.asciidoc View File

@@ -19,7 +19,7 @@ The component state is usually managed by a __shared state__, described later in
<<dummy/../../../framework/gwt/gwt-shared-state#gwt.shared-state,"Shared
State">>.

[source, java]
----
public class MyComponent extends AbstractComponent {
public MyComponent() {

+ 14
- 14
documentation/gwt/gwt-shared-state.asciidoc View File

@@ -16,7 +16,7 @@ A shared state object simply needs to extend the
[classname]#AbstractComponentState#. The member variables should normally be
declared as public.

[source, java]
----
public class MyComponentState extends AbstractComponentState {
public String text;
@@ -42,7 +42,7 @@ and other classes needed by shared-state or RPC communication.
For example, you could have the following definitions in the
[filename]#.gwt.xml# descriptor:

[source, xml]
----
<source path="client" />
<source path="shared" />
@@ -59,7 +59,7 @@ A server-side component can access the shared state with the
implementation with one that returns the shared state object cast to the proper
type, as follows:

[source, java]
----
@Override
public MyComponentState getState() {
@@ -70,7 +70,7 @@ public MyComponentState getState() {
You can then use the [methodname]#getState()# to access the shared state object
with the proper type.

[source, java]
----
public MyComponent() {
getState().setText("This is the initial state");
@@ -86,7 +86,7 @@ A connector can access a shared state with the [methodname]#getState()# method.
The access should be read-only. It is required that you override the base
implementation with one that returns the proper shared state type, as follows:

[source, java]
----
@Override
public MyComponentState getState() {
@@ -99,7 +99,7 @@ client-side. When a state change occurs, the [methodname]#onStateChanged()#
method in the connector is called. You should always call the superclass
method before anything else to handle changes to common component properties.

[source, java]
----
@Override
public void onStateChanged(StateChangeEvent stateChangeEvent) {
@@ -141,7 +141,7 @@ separately in arbitrary order.
We can replace the [methodname]#onStateChange()# method in the earlier connector
example with the following:

[source, java]
----
@OnStateChange("text")
void updateText() {
@@ -164,7 +164,7 @@ defines automatic delegation of the property value to the corresponding widget
property of the same name and type, by calling the respective setter for the
property in the widget.

[source, java]
----
public class MyComponentState extends AbstractComponentState {
@DelegateToWidget
@@ -178,7 +178,7 @@ example in <<gwt.shared-state.onstatechange>>.
If you want to delegate a shared state property to a widget property of another
name, you can give the property name as a string parameter for the annotation.

[source, java]
----
public class MyComponentState extends AbstractComponentState {
@DelegateToWidget("description")
@@ -196,7 +196,7 @@ only refer to a server-side component, while on the client-side you only have
widgets. References to components can be made by referring to their connectors
(all server-side components implement the [interfacename]#Connector# interface).

[source, java]
----
public class MyComponentState extends AbstractComponentState {
public Connector otherComponent;
@@ -205,7 +205,7 @@ public class MyComponentState extends AbstractComponentState {

You could then access the component on the server-side as follows:

[source, java]
----
public class MyComponent {
public void MyComponent(Component otherComponent) {
@@ -241,7 +241,7 @@ serialized to the client-side separately.

Let us begin with the server-side API:

[source, java]
----
public class MyComponent extends AbstractComponent {
...
@@ -259,7 +259,7 @@ public class MyComponent extends AbstractComponent {
On the client-side, you can then get the URL of the resource with
[methodname]#getResourceUrl()#.

[source, java]
----
@Override
public void onStateChanged(StateChangeEvent stateChangeEvent) {
@@ -273,7 +273,7 @@ public void onStateChanged(StateChangeEvent stateChangeEvent) {

The widget could then use the URL, for example, as follows:

[source, java]
----
public class MyWidget extends Label {
...

+ 1
- 1
documentation/gwt/gwt-styling.asciidoc View File

@@ -22,7 +22,7 @@ sub-elements as it desires.
For example, you could style a composite widget with an overall style and with
separate styles for the sub-widgets as follows:

[source, java]
----
public class MyPickerWidget extends ComplexPanel {
public static final String CLASSNAME = "mypicker";

Write Preview
Loading…
Cancel
Save