« Return to Thread: Proposed API change

Re: Proposed API change

by Lance Java :: Rate this Message:

Reply to Author | View in Thread

Can we have two methods?

Util.setValue("id", 42)
Util.setValue(scriptSessions, "id", value);

On 15/04/2008, Joe Walker <joe@...> wrote:

Generally you do something like this to use reverse ajax:

ScriptSession ss = WebContextFactory.get().getScriptSession();
Util util = new Util(ss);
util.setValue("id", 42);

We could alter Util to contain static methods to allow you to do this:

Util.setValue("id", 42);

How would this work with out-of-DWR-thread calls and calls that affect many users?

Collection cs = ServerContextFactory.get().getScriptAllSession();
ServerContextFactory.setScriptEnvironment(cs);
Util.setValue("id", 42);
ServerContextFactory.unsetScriptEnvironment();

or maybe we'd prefer:

Collection cs = ServerContextFactory.get().getScriptAllSession();
ServerContextFactory.withEnvironment(cs, new Runnable() {
   public void run() {
       Util.setValue("id", 42);
   }
});

Why might we want to do this?
There are several reasons:

1. We can more easily write code that affects some users without knowing who those users are
2. We've simplified the most common case
3. APIs like org.directwebremoting.proxy.browser.Window make far more sense this way.
4. This could allow us to transparently port complex APIs to use reverse ajax. For example:

import com.google.gwt.user.client.Window;
// Called by some event handler:
public void event() {
 Window.alert("Hello, World");
}

When compiled for the client this does the normal client side GWT stuff, but when compiled against DWR generated proxies on the server, the same code can use reverse ajax:

Collection cs = ServerContextFactory.get().getScriptAllSession();
ServerContextFactory.withEnvironment(cs, new Runnable() {
   public void run() {
      event();
   }
});

Much of the work I was doing for TIBCO was to create a reverse ajax proxy generator. I think that with this change we could use it against virtually any API.

I've used GWT as an example, but we shouldn't get hung up on GWT (I'm sure there are issues with Javascript compression that make this one hard) - this applies to any API that we wish to adapt to use Reverse Ajax. I know that there are a number of issues with the GI API that would be cleared up with this change.

Joe.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


 « Return to Thread: Proposed API change