New callbackArg option causing conflict when delegating functions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

New callbackArg option causing conflict when delegating functions

ramzi.abbyad
Hello,

We are upgrading from DWR2.0.8 to DWR3 RC3.  

This email is with regards to the javascript function
dwr.engine.remote.handleCallback, in the engine.js script.  I believe
there is a conflict between this method and, for instance,
createDelegate of the ExtJS library (or any case where code calls some
variant of the predefined javascript "apply" function ).  

Since our client-side code uses the ExtJS library extensively, our code
is littered with statements like the following:

Remote.remoter(param1, param2, {
  callback: func1.createDelegate(this, [arg1, arg2], true),
  errorHandler: func2
})

See:
http://docs.sencha.com/extjs/3.4.0/#!/api/Function-method-createDelegat
e

The problem is, the new callbackArg option is being applied to the
parameter list of the callback handler regardless of whether it is
explicitly set by the programmer or not.

This causes a conflict when createDelegate tries to append arguments to
the callback function. The effect is that the arguments passed to
createDelegate will be shifted to the right 1 spot from their
intentional position in the arguments list- thus breaking all existing
code which makes use of this functionality.  

Please have a look at it if you can.  For the time being I have patched
the code with:

    /**
     * Execute a callback
     * @private
     * @param {int} batchId The ID of the batch that we are replying to
     * @param {int} callId The call ID that the script relates to
     * @param {String} reply The script to execute
     */
    handleCallback:function(batchId, callId, reply) {
      var batch = dwr.engine._batches[batchId];
      if (!batch) return;

      // We store the reply in the batch so we can return the data when
in sync mode
      batch.reply = reply;

      // Error handlers inside here indicate an error that is nothing
to do
      // with DWR so we handle them differently.
      try {
        var handlers = batch.handlers[callId];
        if (!handlers) {
          dwr.engine._debug("Warning: Missing handlers. callId=" +
callId, true);
        }
        else {
          batch.handlers[callId].completed = true;
          if (typeof handlers.callback == "function") {
            dwr.engine.util.logHandlerEx(function() {
                if(handlers.callbackArg)
                    handlers.callback.apply(handlers.callbackScope,
[reply, handlers.callbackArg]);
                else
                    handlers.callback.apply(handlers.callbackScope,
[reply]);
            });
          }
        }
      }
      catch (ex) {
        dwr.engine._handleError(batch, ex);
      }
    }

Many Thanks,

Ramzi
Reply | Threaded
Open this post in threaded view
|

Re: New callbackArg option causing conflict when delegating functions

david@butterdev.com
Thanks for the report.  I have logged an issue:
https://directwebremoting.atlassian.net/browse/DWR-635

On 2015-04-09 08:41, [hidden email] wrote:

> Hello,
>
> We are upgrading from DWR2.0.8 to DWR3 RC3.
>
> This email is with regards to the javascript function
> dwr.engine.remote.handleCallback, in the engine.js script.  I believe
> there is a conflict between this method and, for instance,
> createDelegate of the ExtJS library (or any case where code calls some
> variant of the predefined javascript "apply" function ).
>
> Since our client-side code uses the ExtJS library extensively, our code
> is littered with statements like the following:
>
> Remote.remoter(param1, param2, {
>   callback: func1.createDelegate(this, [arg1, arg2], true),
>   errorHandler: func2
> })
>
> See:
> http://docs.sencha.com/extjs/3.4.0/#!/api/Function-method-createDelegat
> e
>
> The problem is, the new callbackArg option is being applied to the
> parameter list of the callback handler regardless of whether it is
> explicitly set by the programmer or not.
>
> This causes a conflict when createDelegate tries to append arguments to
> the callback function. The effect is that the arguments passed to
> createDelegate will be shifted to the right 1 spot from their
> intentional position in the arguments list- thus breaking all existing
> code which makes use of this functionality.
>
> Please have a look at it if you can.  For the time being I have patched
> the code with:
>
>     /**
>      * Execute a callback
>      * @private
>      * @param {int} batchId The ID of the batch that we are replying to
>      * @param {int} callId The call ID that the script relates to
>      * @param {String} reply The script to execute
>      */
>     handleCallback:function(batchId, callId, reply) {
>       var batch = dwr.engine._batches[batchId];
>       if (!batch) return;
>
>       // We store the reply in the batch so we can return the data when
> in sync mode
>       batch.reply = reply;
>
>       // Error handlers inside here indicate an error that is nothing
> to do
>       // with DWR so we handle them differently.
>       try {
> var handlers = batch.handlers[callId];
> if (!handlers) {
>  dwr.engine._debug("Warning: Missing handlers. callId=" +
> callId, true);
> }
> else {
>  batch.handlers[callId].completed = true;
>  if (typeof handlers.callback == "function") {
>    dwr.engine.util.logHandlerEx(function() {
> if(handlers.callbackArg)
>    handlers.callback.apply(handlers.callbackScope,
> [reply, handlers.callbackArg]);
> else
>    handlers.callback.apply(handlers.callbackScope,
> [reply]);
>    });
>  }
> }
>       }
>       catch (ex) {
> dwr.engine._handleError(batch, ex);
>       }
>     }
>
> Many Thanks,
>
> Ramzi
Reply | Threaded
Open this post in threaded view
|

Re: New callbackArg option causing conflict when delegating functions

Mike Wilson
Administrator
Fix implemented and available in development builds starting from:
http://ci.directwebremoting.org/bamboo/browse/DWRTRUNK-ALL-583/artifact/JOB1
/dwr.jar/dwr.jar

Best regards
Mike

david wrote:

> Thanks for the report.  I have logged an issue:
> https://directwebremoting.atlassian.net/browse/DWR-635
>
> On 2015-04-09 08:41, [hidden email] wrote:
> > Hello,
> >
> > We are upgrading from DWR2.0.8 to DWR3 RC3.
> >
> > This email is with regards to the javascript function
> > dwr.engine.remote.handleCallback, in the engine.js script.  
> I believe
> > there is a conflict between this method and, for instance,
> > createDelegate of the ExtJS library (or any case where code
> calls some
> > variant of the predefined javascript "apply" function ).
> >
> > Since our client-side code uses the ExtJS library
> extensively, our code
> > is littered with statements like the following:
> >
> > Remote.remoter(param1, param2, {
> >   callback: func1.createDelegate(this, [arg1, arg2], true),
> >   errorHandler: func2
> > })
> >
> > See:
> >
> http://docs.sencha.com/extjs/3.4.0/#!/api/Function-method-crea
> teDelegat
> > e
> >
> > The problem is, the new callbackArg option is being applied to the
> > parameter list of the callback handler regardless of whether it is
> > explicitly set by the programmer or not.
> >
> > This causes a conflict when createDelegate tries to append
> arguments to
> > the callback function. The effect is that the
> arguments passed to
> > createDelegate will be shifted to the right 1 spot from their
> > intentional position in the arguments list- thus breaking
> all existing
> > code which makes use of this functionality.
> >
> > Please have a look at it if you can.  For the time being I
> have patched
> > the code with:
> >
> >     /**
> >      * Execute a callback
> >      * @private
> >      * @param {int} batchId The ID of the batch that we are
> replying to
> >      * @param {int} callId The call ID that the script relates to
> >      * @param {String} reply The script to execute
> >      */
> >     handleCallback:function(batchId, callId, reply) {
> >       var batch = dwr.engine._batches[batchId];
> >       if (!batch) return;
> >
> >       // We store the reply in the batch so we can return
> the data when
> > in sync mode
> >       batch.reply = reply;
> >
> >       // Error handlers inside here indicate an error that
> is nothing
> > to do
> >       // with DWR so we handle them differently.
> >       try {
> > var handlers = batch.handlers[callId];
> > if (!handlers) {
> >  dwr.engine._debug("Warning: Missing handlers. callId=" +
> > callId, true);
> > }
> > else {
> >  batch.handlers[callId].completed = true;
> >  if (typeof handlers.callback == "function") {
> >    dwr.engine.util.logHandlerEx(function() {
> > if(handlers.callbackArg)
> >    handlers.callback.apply(handlers.callbackScope,
> > [reply, handlers.callbackArg]);
> > else
> >    handlers.callback.apply(handlers.callbackScope,
> > [reply]);
> >    });
> >  }
> > }
> >       }
> >       catch (ex) {
> > dwr.engine._handleError(batch, ex);
> >       }
> >     }
> >
> > Many Thanks,
> >
> > Ramzi