我面临这个问题:单击按钮后,我向服务器发出请求并获取一些数据;然后,我在新页面/视图上显示数据。这就产生了一个问题:在发出请求以及在视图上接收、解析和设置数据时,UI 必须等待。这导致用户必须等到所有数据加载完毕才能返回,甚至没有机会取消调用。多线程可以解决这个问题,这就是我需要帮助的地方。
HTML5 Web Workers 可以帮我解决这个问题,但是我不想在 JSNI 中对它们进行“硬编码”,并且所有调用都使用 Javascript 而不是 GWT Java (RequestBuilder) 编写。我读过有关 DeferredCommand 的内容,但我也不认为它是我问题的答案。
有什么建议吗?或者目前这是不可能的优化?
I'm facing this problem: after clicking on a button, I make a request to the server and get some data; then, I display the data on a new page/view. This raises a problem: the UI has to wait while the request is being made and data is being received, parsed and set on the view. This results in the user having to wait until all the data is loaded before even being able to go back, and doesn't even have the chance to cancel the call. Multithreading would solve the issue, and that's where I need help.
The HTML5 Web Workers would do the trick for me, however I don't want to "hard code" them in JSNI and have all the calls written with Javascript instead of GWT Java (RequestBuilder). I've read about DeferredCommand but I also don't think it's the answer to my issue.
Any suggestions? Or this is an impossible optimization, at the moment?
发布评论
评论(1)
在 JS 中,因此在 GWT 中,没有多线程。相反,您应该使用带有回调的异步调用。通常,当您使用 GWT RPC 进行通信时,您会发出请求并在
onSuccess
事件中处理结果。或者,您始终可以使用定时器
定期检查结果。我不确定你提出什么样的要求,所以很难具体。也许您应该检查与服务器通信的相应部分编辑:我刚刚注意到您提到RequestBuilder。 sendRequest() 不应阻止执行,您应该在提供的回调的
RequestCallback.onResponseReceived()
中处理结果。这意味着您以某种方式继续在该回调中处理按钮事件。In JS, therefore GWT, there is no multithreading. Instead you should use asynchronous calls with callbacks. Normally when you use GWT RPC for communication, you issue a request and handle result in
onSuccess
event. Alternatively you can always useTimer
to check for result periodically. I'm not sure what kind of request you are making, so hard to be specific. Probably you should check appropriate section of Communicating with the serverEDIT: I've just noticed you mention RequestBuilder. The sendRequest() should not block execution and you should process result in
RequestCallback.onResponseReceived()
of provided callback. Which mean you somehow continue your button event handling in that callback.