Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 397569

Summary:	[client] Provide public client API for global "system" events/callbacks
Product:	[RT] RAP	Reporter:	Tim Buschtoens <tbuschto>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	tbuschto
Version:	2.0
Target Milestone:	2.0 RC1
Hardware:	All
OS:	All
Whiteboard:

Description Tim Buschtoens

2013-01-07 09:02:16 EST

We noticed several cases where it might be useful (or necessary) to get  notified of certain events on the client that are not associated with any widget.

Examples:
- http request is about to be sent: last opportunity to attach operations
- message has been processed completely: enables optimized/lazy dom rendering
- connection error/offline mode: allow custom offline behavior, e.g. show a shell
- drag start/stop, dialog/popup shown/hidden: see Bug 397557

There are of course many more possible events, but those are what i consider useful right now, especially the first two. 

These events should be provided by the "rap" object (perhaps it could also be a possible target in ClientScripting). To me it seems useful to provide three methods: register a listener, remove a listener, register listener for only one execution.

I would suggest to use a similar or identical listener API to whatever we decide to use in Bug 397548.

Comment 1 Tim Buschtoens

2013-01-08 08:46:28 EST

We will deliberately use a different event API than SWT/ClientScripting, to make it clear that the "rap" object is not part of the Widget Toolkit and behaves differently. ("rap" also is no clientObject, has no instances, provides no event objects, etc.). The API will be:

rap.on( "eventtype", handler );
rap.off( "eventtype", handler );

A "once" (or similar) method may be introduced later. Event names will be all lowercase and the handler will be executed in global context only. De-registering (e.g. on destroy) is currently completely the responsibility of the widget/handler code, and registering an inline anonymous function would make it impossible to do so. A simplified or alternative way to (de-)register listener may therefore built on top of this API later on.

The events will be "send" and "render".

Comment 2 Tim Buschtoens

2013-01-10 06:04:37 EST

Fixed with commit 2681ced8cc26960dd80d4cde5162b90a9dafd767