如何拦截GWT中的onSuccess()方法

发布于 2024-10-22 04:01:06 字数 268 浏览 1 评论 0原文

我需要对 GWT 中的 onSuccess 方法进行方法拦截。

我需要在 GWT 中调用 onSuccess 方法之前之后添加一些代码吗? (我对 onSuccess 方法进行了多次调用,并且需要动态执行此操作)

编辑: 我需要在屏幕右上角添加一个进度条,该进度条在代码进入onsuccess方法时出现,并在退出onsuccess方法时消失代码>方法。

I need to do method interception for the onSuccess method in GWT.

I need to add some code before and after the calling of the onSuccess method in GWT? (I have many calls to the onSuccess method and I need to do this dynamically)

EDIT:
I need to add a progress bar in the right corner of the screen, that appears when the code enters the onsuccess method and disappears on the exit of onsuccess method.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

绝對不後悔。 2024-10-29 04:01:06

嗯,这是一个通用的非功能性需求,我对此项目做了一些研究,我已经实现了 Thomas Broyer 在 gwt group.. 该解决方案比其他建议的解决方案具有明显的优势,您不必更改回调类,您所要做的只是添加一个创建异步 gwt-rpc 服务后的代码行...

IGwtPersistenceEngineRPCAsync persistenceEngine = GWT.create(IGwtPersistenceEngineRPC.class);
     ((ServiceDefTarget) persistenceEngine).setRpcRequestBuilder(new ProgressRequestBuilder());


import com.allen_sauer.gwt.log.client.Log;
import com.google.gwt.http.client.Request;
import com.google.gwt.http.client.RequestBuilder;
import com.google.gwt.http.client.RequestCallback;
import com.google.gwt.http.client.Response;
import com.google.gwt.user.client.rpc.RpcRequestBuilder;

public class ProgressRequestBuilder extends RpcRequestBuilder {

    private class RequestCallbackWrapper implements RequestCallback {

        private RequestCallback callback;

        RequestCallbackWrapper(RequestCallback aCallback) {
            this.callback = aCallback;
        }

        @Override
        public void onResponseReceived(Request request, Response response) {
            Log.debug("onResposenReceived is called");
            // put the code to hide your progress bar
            callback.onResponseReceived(request, response);

        }

        @Override
        public void onError(Request request, Throwable exception) {
            Log.error("onError is called",new Exception(exception));
            // put the code to hide your progress bar
            callback.onError(request, exception);

        }

    }



    @Override  
    protected RequestBuilder doCreate(String serviceEntryPoint) {

        RequestBuilder rb = super.doCreate(serviceEntryPoint);
        // put the code to show your progress bar           
        return rb;  
    }

    @Override
     protected void doFinish(RequestBuilder rb) {
         super.doFinish(rb);
         rb.setCallback(new RequestCallbackWrapper(rb.getCallback()));

     }

}

Well, it is a generic non-functional requirement, I have done some research on this item, I have implemented a solution that Thomas Broyer has suggested on gwt group.. This solution has distinct advantage over other suggested solutions, You dont have to change your callback classes, what you have to do is just add a line of code after creation of async gwt-rpc service...

IGwtPersistenceEngineRPCAsync persistenceEngine = GWT.create(IGwtPersistenceEngineRPC.class);
     ((ServiceDefTarget) persistenceEngine).setRpcRequestBuilder(new ProgressRequestBuilder());


import com.allen_sauer.gwt.log.client.Log;
import com.google.gwt.http.client.Request;
import com.google.gwt.http.client.RequestBuilder;
import com.google.gwt.http.client.RequestCallback;
import com.google.gwt.http.client.Response;
import com.google.gwt.user.client.rpc.RpcRequestBuilder;

public class ProgressRequestBuilder extends RpcRequestBuilder {

    private class RequestCallbackWrapper implements RequestCallback {

        private RequestCallback callback;

        RequestCallbackWrapper(RequestCallback aCallback) {
            this.callback = aCallback;
        }

        @Override
        public void onResponseReceived(Request request, Response response) {
            Log.debug("onResposenReceived is called");
            // put the code to hide your progress bar
            callback.onResponseReceived(request, response);

        }

        @Override
        public void onError(Request request, Throwable exception) {
            Log.error("onError is called",new Exception(exception));
            // put the code to hide your progress bar
            callback.onError(request, exception);

        }

    }



    @Override  
    protected RequestBuilder doCreate(String serviceEntryPoint) {

        RequestBuilder rb = super.doCreate(serviceEntryPoint);
        // put the code to show your progress bar           
        return rb;  
    }

    @Override
     protected void doFinish(RequestBuilder rb) {
         super.doFinish(rb);
         rb.setCallback(new RequestCallbackWrapper(rb.getCallback()));

     }

}
忘你却要生生世世 2024-10-29 04:01:06

从视觉角度来看,

void onSuccess(Value v) {
  showProgressBar();
  doLotsOfWork(v);
  hideProgressBar();
}

这将是一个空操作。浏览器通常会等待事件处理程序完成执行,然后再重新渲染 DOM。如果doLotsOfWork()方法的执行时间较长(例如>100ms),则由于JavaScript执行的单线程特性,用户会注意到浏览器出现卡顿。

相反,请考虑使用 增量调度命令来分解工作。它大致看起来像:

void onSuccess(Value v) {
  showProgressBar();
  Scheduler.get().scheduleIncremental(new RepeatingCommand() {
    int count = 0;
    int size = v.getElements().size();
    public boolean execute() {
      if (count == size) {
        hideProgressBar();
        return false;
      }
      processOneElement(v.getElements().get(count++));
      setProgressBar((double) count / size);
      return true;
    }
  });
}

通过打破浏览器事件循环的多个泵的工作,您可以避免在需要完成大量工作时 Web 应用程序变得无响应的情况。

From a visual perspective

void onSuccess(Value v) {
  showProgressBar();
  doLotsOfWork(v);
  hideProgressBar();
}

will be a no-op. Browsers typically wait for event handlers to finish executing before re-rending the DOM. If the doLotsOfWork() method takes a noticeable amount of time to execute (e.g. >100ms) the user will notice the browser hiccup due to the single-threaded nature of JavaScript execution.

Instead, consider using an incrementally-scheduled command to break the work up. It would look roughly like:

void onSuccess(Value v) {
  showProgressBar();
  Scheduler.get().scheduleIncremental(new RepeatingCommand() {
    int count = 0;
    int size = v.getElements().size();
    public boolean execute() {
      if (count == size) {
        hideProgressBar();
        return false;
      }
      processOneElement(v.getElements().get(count++));
      setProgressBar((double) count / size);
      return true;
    }
  });
}

By breaking the work across multiple pumps of the browser's event loop, you avoid the situation where the webapp becomes non-responsive if there's a non-trivial amount of work to do.

温柔一刀 2024-10-29 04:01:06

你不能那样做。 rpc onSuccess() 方法异步运行(换句话说,取决于服务器何时完成,应用程序不会等待它)。您可以在 RPC 调用之后立即触发代码,该代码可能/可能不会在 RPC 调用的 onSuccess 之前完成。

你能用一个例子解释一下为什么你要这么做吗?由于这种异步行为,您可能必须重新设计应用程序,但在您提供用例之前不能说。最好在 rpc 调用之后忘记任何异步功能,并且仅在 onSuccess 中执行操作。

You cant do that. The rpc onSuccess() method runs asynchronously (in other words, depends on the server when it completes, the app doesnt wait for it). You could fire code immediately after the rpc call which may/ may not complete before the onSuccess for RPC calls.

Can you explain with an eg why exactly do u want to do that? Chances are you might have to redesign the app due to this async behavior, but cant say till you provide a use case. Preferably any Async functionality should be forgotten after the rpc call, and actioned upon only in the onSuccess.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文