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

Bug 388835

Summary:	[protocol] update non-widget protocol object-types handling
Product:	[RT] RAP	Reporter:	Tim Buschtoens <tbuschto>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	tbuschto
Version:	2.0
Target Milestone:	2.0 M3
Hardware:	All
OS:	All
Whiteboard:

Description Tim Buschtoens

2012-09-05 06:04:45 EDT

There are currently some protocol object-types that are directly in the "rwt" namespace. (Within the rwt core.) These are:

* "rwt.GC"
* "rwt.Display"

* "rwt.UICallBack"
* "rwt.JSExecutor"
* "rwt.BrowserHistory"

Sine we are naming the protocol-types like the javascript files they match, and becuse we don't want any classes/object in the "rwt" namespace, they are going to be renamed. The first two are moving in the "rwt.widgets" namespace (even though they technically aren't widgets), the other to the "rwt.client" namespace. TextSizeDetermination, which is currently still handled by the display object, will also be placed there. 

In Addition, object that can't reasonably have multiple instances (like singleton/static classes) are no longer going to be created in the protocol, but (again) use pre-defined ids. These IDs will be the type. Therefore we will have these changes:

* "rwt.GC" will become "rwt.widgets.GC"
* "rwt.Display" will become "rwt.widgets.Display"
* We will have these objects-ids pre-defined without a create operation:
 * "rwt.client.UICallBack"
 * "rwt.client.JSExecutor"
 * "rwt.client.BrowserHistory"
 * "rwt.client.TextSizeDetermination"

These changes should ideally be in M2, but details might still change until then.

Comment 1 Tim Buschtoens

2012-09-28 05:26:03 EDT

These changes will not be in M2.

However, commit b30230d5b887bfeda8f6907eee114341fffdf6c3 implements a temporary workaround for history, which in some cases might require sending operations without having been created yet.

Comment 2 Tim Buschtoens

2012-09-28 05:36:54 EDT

My suggestion would be to have a flag in the client protocol adapters like "static : true" or "isStatic : true". ("static" would have to be in "", which we currently don't do for keys in adapters.) Then AdapterRegistry or some util class could create entries for these objects in the ObjectRegistry when System.js is processed. The type would be the id. Create operations would be illegal for these types.

Alternatively, a new key like "staticId" or "customId" or "predefinedId" or just "id" could be used to explicitly assign a pre-defined id. Unlike the other approach, this does not set the relationship between type and id in store, which could be good or bad. (I think it's bad, the id should not be able to be any random value).

Comment 3 Tim Buschtoens

2012-10-09 11:30:34 EDT

Fixed with commit 86804e679b0eb58d8ac9d5b208f54c6abe710ab5.

Client-side protocol adapter can have a field "service" set to true. In that case the object can not be created, but will be available without creation with the id identical to the type. This pattern is now used for JSExecuter, UICallBack and BrowserHistory. I also renamed the types to include "client" in the namespace.

GC, Display are not yet renamed. TextSizeDeterminatation does not yet exist as a type, it's still part of Display.

Comment 4 Tim Buschtoens

2012-10-10 04:49:25 EDT

commit e02cbf37a6dd0d6294a3de1861d465d59c19d172 also fixes GC and Display naming. TextSizeDetermination will be dealt with in Bug 388731 .