Revert "Merge branch 'documentation'"7.6.0.beta2

This reverts commit f6874bde3d945c8b2d1b5c17ab50e2d0f1f8ff00.

Change-Id: I67ee1c30ba3e3bcc3c43a1dd2e73a822791514bf

1 files changed, 0 insertions, 74 deletions

diff --git a/documentation/architecture/architecture-events.asciidoc b/documentation/architecture/architecture-events.asciidoc
deleted file mode 100644
index e832c581fe..0000000000
--- a/documentation/architecture/architecture-events.asciidoc
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: Events and Listeners
-order: 4
-layout: page
----
-
-[[architecture.events]]
-= Events and Listeners
-
-Vaadin offers an event-driven programming model for handling user interaction.
-When a user does something in the user interface, such as clicks a button or
-selects an item, the application needs to know about it. Many Java-based user
-interface frameworks follow the __Event-Listener pattern__ (also known as the
-Observer design pattern) to communicate user input to the application logic. So
-does Vaadin. The design pattern involves two kinds of elements: an object that
-generates ("fires" or "emits") events and a number of listeners that listen for
-the events. When such an event occurs, the object sends a notification about it
-to all the listeners. In a typical case, there is only one listener.
-
-Events can serve many kinds of purposes. In Vaadin, the usual purpose of events
-is handling user interaction in a user interface. Session management can require
-special events, such as time-out, in which case the event would actually be the
-lack of user interaction. Time-out is a special case of timed or scheduled
-events, where an event occurs at a specific date and time or when a set time has
-passed.
-
-To receive events of a particular type, an application must register a listener
-object with the event source. The listeners are registered in the components
-with an [methodname]#add*Listener()# method (with a method name specific to the
-listener).
-
-Most components that have related events define their own event class and the
-corresponding listener class. For example, the [classname]#Button# has
-[classname]#Button.ClickEvent# events, which can be listened to through the
-[classname]#Button.ClickListener# interface.
-
-In the following, we handle button clicks with a listener implemented as an
-anonymous class:
-
-
-[source, java]
-----
-final Button button = new Button("Push it!");
-
-button.addClickListener(new Button.ClickListener() {
-    public void buttonClick(ClickEvent event) {
-        button.setCaption("You pushed it!");
-    }
-});
-----
-
-<<figure.eventlistenerdiagram>> illustrates the case where an
-application-specific class inherits the [classname]#Button.ClickListener#
-interface to be able to listen for button click events. The application must
-instantiate the listener class and register it with
-[methodname]#addClickListener()#. It can be an anonymous class, such as the one
-above. When an event occurs, an event object is instantiated, in this case a
-[classname]#Button.ClickEvent#. The event object knows the related UI component,
-in this case the [classname]#Button#.
-
-[[figure.eventlistenerdiagram]]
-.Class Diagram of a Button Click Listener
-image::img/events-classdiagram-hi.png[]
-
-In the ancient times of C programming, __callback functions__ filled largely the
-same need as listeners do now. In object-oriented languages, we usually only
-have classes and methods, not functions, so the application has to give a class
-interface instead of a callback function pointer to the framework.
-
-<<dummy/../../../framework/application/application-events#application.events,"Handling
-Events with Listeners">> goes into details of handling events in practice.
-
-
-