Community
Participate
Working Groups
Both the RWT widget on the server and the ClientScripting widget object have setData and getDate methods. However, the data is not synchronized between the two, which would be very useful to easily customize the widget behavior from java without changing the ClientListener. Not all data should (or can) be synchronized. Options to select the data to be synchronized from server to client would be: * Use a prefix like for the key to mark the data to be synchronized. * All synchronizable data must be of a certain class (like ClientData), or extend such a class. * Use a Adapter pattern to have a separate userData map. Synchronizing from client to server is not very useful as far as i can tell. It should be handled in a separate bug if the need arises. However, there might be a need to notify the client about changes in the userData.
I propose an alternative: Add a map to the listener-widget binding which defines the context in which event is executed. No synchronizing (yet), just create the map together with the binding. Its much less work, enables interaction between widgets and allows to use different parameters for the same listener depending on the widget. I actually already implemented a slightly limited version of this as a test, and it seems to work fine: https://github.com/eclipsesource/rap-clientscripting/tree/experimental We should definitely implement something like this that is compatible with the 1.5 release, i.e. before we make changes to ClientScripting that are based on RAP 2.0 development. That way ClientScripting is a useale option for custom widget development with 1.5.
Regarding Comment#1, i guess it's too late to bother with anything regarding RAP 1.5. My personal preference right now would be to allow ClientFunctions (a new superclass to ClientListener) to be called from Java with arguments. It could be a very powerful tool in general, especially all kind of data-binding could build on it. That way client-side setData could be freely used without bothering with the many details that would make automatically synchronizing user data between server and client (by protocol, bi-directional) complicated. Example: ClientFunction setData = new ClientFunction( "setData", "function setData( widget, key, value ){ widget.setData( key, value );" ); setData.call( myJavaWidget, "foo", "bar" ); setData.call( myJavaWidget2, "foo2", "bar2" ); ... setData.dispose(); For the other direction there could be a ServerFunction counterpart. However, there also seems to be some interest to synchronize data that is already attached to a widget (could also be useful for custom clients). In that approach there would have to be a list of keys to synchronize somewhere. Perhaps both ideas are not mutually exclusive.
*** Bug 400688 has been marked as a duplicate of this bug. ***
There is already support for an "WidgetDataWhiteList" Service that allows to sync some user data to the client. However, it is curently not implemented for the WebClient. We should add an implementation, but keep it internal until we are sure about the API.
With commit 622de8ff3b195a89cc2eecf18efd383b92aa9b52 the WidgetDataWhiteList service is supported in the WebClient as an internal service. The ClientScripting repository has been updated with commit 17a3ff13a2637b494eb93b63a05411ae579f6a61 to be able to read the fields given by the WhiteList to the client.
We should make the WidgetDataWhiteList service public API to make it possible for developers to use it with ClientScripting. I'm not satisfied with the current experimental API which consists of setKeys and getKeys. If two independent components try to use the service, they will overwrite each others vaues. Instead I propose to have addKeys only. getKeys could be internal, as it is of no interest to the application developer. If the same keys are added multiple times it should have no effect. There should be no removeKeys either, as it could lead to a ton of confusing situations.
Not sure if this is a good idea anymore, it's somewhat akward getting my data from the widget.getData method in ClientScripting, and the API for the way WidgetDataWhitelist works isn't very intuitive. I would prefere adding data to the ClientListeners directly.
But getData/setData it´s I think the only intuitive way to exchange widget related data between JavaScript- and Java-part working both ways. Especially if there are many different information to exchange. For the keys - isn´t it be possible to internally add the widget id to the key, so the key names are unique? Because overwriting data for a different widget is also a problem, not only the impossibility to insert a key which is already defined. Regards Waldemar
Replaced WidgetDataWhiteList service with WidgetUtil#registerDataKeys with commit 26adaf4498e36eb40c2259a819d6191806fc3701.
