I'm not a fan of that null either and the autimagic population thing is something I've used a lot so I'd hate to have to update my code like that when it is time to upgrade DWR.

If there really is a technical difficulty and there has to be a breaking change, might I suggest an IoC-like approach? If the remoted class has a public setHttpRequest() method then it is called. Ditto for session and response and whatever else... That way the method calls remain clean and it actually might be more flexible that way.

Frank

From: Jose Noheda <jose.noheda-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Monday, September 01, 2008 8:56 AM
To: users-EyPigyGktj4FDOXUYO6UHQ@public.gmane.org
Subject: Re: [dwr-user] E14 / DWR-274: Allow overloaded method access

On Mon, Sep 1, 2008 at 1:51 PM, Joe Walker <joe-klYz7rYGnPJg9hUCZPvPmw@public.gmane.org> wrote:

I've checked in a change over the weekend to allow DWR to allow overloaded methods.
This has broken 2 edge cases:

Auto-fill Servlet Parameters

Suppose you have:
  public class Remote {
    public void method(HttpServletResponse r, int i) { ...}
  }

You used to be able to call it with:
  Remote.method(42);

And DWR would magically fill in the HttpServletResponse from the XHR request. Working out where to put parameters in the presence of varargs and overloading could be too complex so now you need to call:
  Remote.method(null, 42);

I don't like the null there. Couldn't we define a constant like HTTP_REQUEST? So it is:

Remote.method(HTTP_REQUEST, 42);

And we are breaking backwards compatibility again (this means extra documentation)
 

Tighter definitions of final arguments

The rules for what would be considered a callback function or callback options object used to take into account the number of parameters to the called function.
With the addition of varargs/overloading support, the rules become simpler:
If the last argument is a function, then is is considered to be the callback function and the remaining arguments are the real arguments.

Fine, most common case
 

If the last argument is an object with a member called callback which is of type function, then the last argument is a callback options object and the rest are real arguments.

Fine again.
 

Otherwise there is no callback function and all arguments are real arguments.

What about a null as last argument? People may be doing it something like it today
 

What does this break?
This used to be a call to Remote.method(42);
  Remote.method(42, { exceptionHandler:function() { ... } });

However after this change it is a call to a method with 2 parameters.

The fix is to call:
  Remote.method(42, { exceptionHandler:function() { ... }, callback:function() {} };

Can't we detect other DWR args as we do with the callback function and make some assumptions? I like the old way better
 

Joe.