Community
Participate
Working Groups
Since there have been recent issues in the newsgroup that could be solved by using the JSExecutor, I wonder if it would make sens to provide a public API for that. I'm using the internal JSExecutor myself to execute arbitrary JS that needs to be executed on the hole page and not only in a Browser widget (closing the page or redirect, dynamically change the browser title). So would it would make sens to provide this class or a similar mechanism as public API or are there more appropriate measures? It would definetely add more flexibility to execute arbitrary JS code but would also expose internals.
We should also consider to provide an API that allows to read request parameters.
I agree that there should be API to execute custom script code on the client. We're going to provide a dedicated slot for this in the protocol. However, I currently don't think that such an API should be limited to JavaScript. Even though the current RAP client can only handle JavaScript, it may become possible to execute code in different languages on a RAP client. I'm thinking about an API with an additional type parameter along the lines of <script type="text/javascript">... in HTML.
We implemented the JavaScriptExecutor as a web client service. Usage: JavaScriptExecutor executor = RWT.getClient().getService( JavaScriptExecutor.class ); if( executor != null ) { executor.execute( javaScriptCode ); }