summaryrefslogtreecommitdiffstats
path: root/documentation/architecture/architecture-events.asciidoc
blob: 75da0f933c59a507c2b2c998af3cea930866a6e4 (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
---
title: Events and Listeners
order: 4
layout: page
---

[[architecture.events]]
= Events and Listeners

Vaadin Framework 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 Framework. 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 Framework, 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# functional interface.

In the following, we assign a button click listener using a lambda expression.

[source, java]
----
final Button button = new Button("Push it!");

button.addClickListener(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()#. 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.png[width=80%, scaledwidth=100%]

<<dummy/../../../framework/application/application-events#application.events,"Handling Events with Listeners">> goes into details of handling events in practice.
t/44295/stable29'>backport/44295/stable29 Nextcloud server, a safe home for all your data: https://github.com/nextcloud/serverwww-data
aboutsummaryrefslogtreecommitdiffstats
path: root/build/integration/remoteapi_features/remote.feature
blob: 62fd95e013015bfb6bf211d3df3a2e027c5c1afd (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
Feature: remote

  Scenario: Get status of remote server
    Given using remote server "REMOTE"
    Then the remote version should be "__current_version__"
    And the remote protocol should be "http"

  Scenario: Get status of a non existing server
    Given using remote server "NON_EXISTING"
    Then the request should throw a "OC\Remote\Api\NotFoundException"

  Scenario: Get user info for a remote user
    Given using remote server "REMOTE"
    And user "user0" exists
    And using credentials "user0", "123456"
    When getting the remote user info for "user0"
    Then the remote user should have userid "user0"

  Scenario: Get user info for a non existing remote user
    Given using remote server "REMOTE"
    And user "user0" exists
    And using credentials "user0", "123456"
    When getting the remote user info for "user_non_existing"
    Then the request should throw a "OC\Remote\Api\NotFoundException"

  Scenario: Get user info with invalid credentials
    Given using remote server "REMOTE"
    And user "user0" exists
    And using credentials "user0", "invalid"
    When getting the remote user info for "user0"
    Then the request should throw a "OC\ForbiddenException"

  Scenario: Get capability of remote server
    Given using remote server "REMOTE"
    And user "user0" exists
    And using credentials "user0", "invalid"
    Then the capability "theming.name" is "OC\ForbiddenException"
    Then the request should throw a "OC\ForbiddenException"