Proposed API change

[Joe Walker-3]

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@...

[Lance Java]

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@...

[Joe Walker-3]

That doesn't answer benefits 1 and 4. So while useful, I think it might be confusing.
Joe

On Tue, Apr 15, 2008 at 1:07 PM, Lance Java <lance.java@...> wrote:

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@...

[Joe Walker-3]

The biggest issue for me is that of backwards compatibility.
I think the best approach is probably to create a new package org.directwebremoting.ui and when that's working properly, deprecate the org.directwebremoting.proxy package, and point people to the new implementations.

Joe.

On Tue, Apr 15, 2008 at 4:00 PM, Joe Walker <joe@...> wrote:

That doesn't answer benefits 1 and 4. So while useful, I think it might be confusing.
Joe

On Tue, Apr 15, 2008 at 1:07 PM, Lance Java <lance.java@...> wrote:

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@...

[Thomas Manson]

Hi Joe,

 

It would be quite useful to be able to filter session the reverse ajax call is done.

 

So maybe something like

 

Util.setValue("id", value); sent reverse to all

 

and another signature :

 

interface SessionFilter

{

   public boolean isFiltered(ScriptSession s);

}

 

Util.setValue("id", value, someCustomImplementationOfSessionFilter);

Thomas

On 4/18/08, Joe Walker <joe@...> wrote:

The biggest issue for me is that of backwards compatibility.
I think the best approach is probably to create a new package org.directwebremoting.ui and when that's working properly, deprecate the org.directwebremoting.proxy package, and point people to the new implementations.

Joe.

On Tue, Apr 15, 2008 at 4:00 PM, Joe Walker <joe@...> wrote:

That doesn't answer benefits 1 and 4. So while useful, I think it might be confusing.
Joe

On Tue, Apr 15, 2008 at 1:07 PM, Lance Java <lance.java@...> wrote:

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@...

 

 

[mikewse]

Joe wrote:

> 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);
>      }
> });

That looks like a cool feature. I would prefer something like
the former syntax as inner classes and runnables always get a
bit too intrusive and verbose for my taste.

I would like to see possibilities for a "shorter" syntax than
your example, maybe

  ServerContextFactory.selectAllScriptSessions();
  Util.setValue("id", 42);

so "all sessions" apply to the rest of this call/request and is
then automatically cleared, no "unset" call. If not selecting
script sessions with the first call then the script session
belonging to the current request (if any) would be used by
default.

Best regards
Mike

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

[Joe Walker-3]

The notion of close is vital.

The reverse proxy APIs could be a lot better if they could generate scripts at some later date, after the actual invocation.
Also the open/close gives you a notion of atomicity. All the code inside a block should execute or none at all.

Although we could auto-close, I would like people to understand what the block is about.
For the time being, I've added the extra methods to 'Browser', along with a filter method that someone else suggested.

There is another potential benefit to the Runnable idea. *In theory* if you are in a clustered environment, maybe the UI code could be distributed to the node or nodes which are connected to the clients in question.

Joe.

On Wed, May 14, 2008 at 4:11 PM, Mike Wilson <mikewse@...> wrote:

Joe wrote:
> 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);
>      }
> });

That looks like a cool feature. I would prefer something like
the former syntax as inner classes and runnables always get a
bit too intrusive and verbose for my taste.

I would like to see possibilities for a "shorter" syntax than
your example, maybe

 ServerContextFactory.selectAllScriptSessions();
 Util.setValue("id", 42);

so "all sessions" apply to the rest of this call/request and is
then automatically cleared, no "unset" call. If not selecting
script sessions with the first call then the script session
belonging to the current request (if any) would be used by
default.

Best regards
Mike

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