Community
Participate
Working Groups
Now that there are alternative clients for RAP in the making, we need some API to obtain a reference to the client that is connected to the current session. This API should allow alternative clients to provide access to device-specific information and capabilities. We came up with the following draft: Client client = RWT.getClient(); Client is an interface that provides a service lookup method. For example, a client could provide a GeoLocationService: GeoLocationService locationService = client.getService( GeoLocationService.class ); The existing WebClient will be the default implementation of this interface.
Created attachment 221512 [details] Example of a custom client Implemented a first version in commit 4aa08df23ac92862861a32bd263ccac82b978c6d. API to register custom clients is still internal. I've attached a simple example of a client implementation.
Regarding services, i think they should be handled in the protocol as static/fixed ids and vice-versa. See Bug 388835 - [protocol] update non-widget protocol object-types handling
Implemented JavaScriptExecutor and BrowserHistory as services.
The Client interface should provide "getLocale" and "getTimeZoneOffset" methods. The information could be sent by the client in the first "head". Maybe Client should become an abstract class so it can implement these two methods itself?
(In reply to comment #4) > Maybe Client should become an abstract class so it can implement these two > methods itself? For me an interface feels better as it provides more flexibility for implementations - it does not tie implementations to a given super class. There's nothing wrong with an abstract base class but I think it should stay internal as long the API to register clients is internal.
Client and ClientService classes are implemented and documented, bug closed.
