Bugzilla – Full Text Bug Listing
| Summary: | [Scripting] Add ClientListener using widget#addListener is not always working | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Tim Buschtoens <tbuschto> | ||||
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | rsternberg, tbuschto | ||||
| Version: | 2.1 | ||||||
| Target Milestone: | 2.2 M1 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
I think that the ClientListener is not intended to be subclassed and should be marked as such. With the current state (ClientScripting out of the RAP core) the check ClientScriptingSupport#isClientListener( Listener ) should not be an expensive operation and should be kept as simple as possible. Looking for ClientListener superclass with reflection will make the thing more complex. Here is what i tried, but it's only fixes half of the problem.
private static final String CLIENT_LISTENER_CLASS_NAME
= "org.eclipse.rap.clientscripting.ClientListener";
private static boolean checkedForClientListenerClass = false;
private static Class clientListenerClass = null;
private static void checkClientListenerClass() {
if( !checkedForClientListenerClass ) {
checkedForClientListenerClass = true;
try {
clientListenerClass = Class.forName( CLIENT_LISTENER_CLASS_NAME );
} catch( ClassNotFoundException e ) {
// there is no ClientListener
}
}
}
public static boolean isClientListener( Listener listener ) {
checkClientListenerClass();
return clientListenerClass != null && clientListenerClass.isInstance( listener );
}
Okay, my SingleSourcing idea may not work after all, as the java handleEvent may be called in addition to the javascrpt handleEvent in some cases. It seems further changes would be needed for this to work, so the entire thing isn't as urgent to me anymore. Created attachment 231639 [details]
Patch
This patch looks for org.eclipse.rap.clientscripting.ClientListener superclass too in ClientScriptingSupport#isClientListener(). It also changes ClientScriptingSupport#findMethod to look into public methods instead of declared methods, because in case of subclassing "addTo" and "removeFrom" are not declared methods.
What do you think Ralf? Having this in 2.1 might make it simpler to implement a 2.1 compatible SingleSourcing solution for ClientScripting, though it doesn't work quite yet. (In reply to comment #5) > What do you think Ralf? Having this in 2.1 might make it simpler to > implement a 2.1 compatible SingleSourcing solution for ClientScripting, > though it doesn't work quite yet. It's neither a regression nor is it a critical bug. Considering this patch for RC3 would be a clear violation of our ramp down plan [1]. Single sourcing capable client listeners are an interesting idea, but it's more a research topic than a requirement we actually have. There are alternative approaches to single-sourcing such as adding platform-dependent listeners in a strategy, as we've done it in the "behaviour" implementations in the clientscripting demo. [1] http://wiki.eclipse.org/RAP/Ramp_down_plan > It's neither a regression nor is it a critical bug. Considering this patch
> for RC3 would be a clear violation of our ramp down plan [1].
Okay, i suspected that.
This was fixed when Scripting moved to the core in M1. |
Consider this code: protected void createContents( Composite parent ) { Text text = new Text( parent, SWT.BORDER ); text.addListener( SWT.Modify, new ClientListener( "function handleEvent( event ) {" + " console.log( event.widget.getText() );" + "}" ) { @Override public void handleEvent( Event event ) { System.out.println( ( ( Text )event.widget ).getText() ); }; } ); This would be a nice approach to SingleSourcing with ClientScripting, but it doesn't work. The listener is created on the client, but not attached. Instead the events are (incorrectly) send to the server. I would love it if we can fix this for 2.1 release.