Home » Eclipse Projects » Remote Application Platform (RAP) » UICallback Mechanism
| UICallback Mechanism [message #64037] |
Mon, 03 December 2007 11:48  |
Eclipse User |
|
|
|
Hi,
after I used it several times, I wanted to look at how this
UICallBack-Mechanism works, but since there is rare JavaDoc at the moment,
I cannot get it completely.
How do you do this? As far as I see, you are sending a request to the
server, which gets blocked until UI-Updates occur?
A word on this would be very much appreciated, thank you.
Martin
|
|
|
| Re: UICallback Mechanism [message #64536 is a reply to message #64037] |
Wed, 05 December 2007 04:18  |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
as you already said, the current implementation blocks a request at the
server-side. In case of Display#syncExec(Runnable) or
Display#asyncExec(Runnable) called from a serverside background thread,
this block gets released. The response triggers a standard UI request that
runs through the normal RWTLifeCycle mechanism. Similarly to SWT there is a
certain time in the lifecycle (respectively eventloop in SWT) where the
registered runnables get excecuted.
As always at the end of the RWT lifecycle changes made during request
processing will be transmitted to the client. In our case the changes are
performed by the registered runnables.
Last but not least another UICallBack request gets blocked so that in case
of the next serverside updates the notification of the client can be
triggered again.
Ciao
Frank
"Martin" <mdilger@splitshade.de> schrieb im Newsbeitrag
news:f03cdde9366b8395fc605498a25ca39e$1@www.eclipse.org...
> Hi,
>
> after I used it several times, I wanted to look at how this
> UICallBack-Mechanism works, but since there is rare JavaDoc at the moment,
> I cannot get it completely.
> How do you do this? As far as I see, you are sending a request to the
> server, which gets blocked until UI-Updates occur?
>
> A word on this would be very much appreciated, thank you.
>
> Martin
>
|
|
| |
| Re: UICallback Mechanism [message #103332 is a reply to message #64536] |
Thu, 28 August 2008 14:16 |
| Eclipse User |
|
|
|
Originally posted by: akarypid.yahoo.gr
I'm also trying to get to grips with the way UICallback works and have
some questions.
My understanding is that the typical lifecycle of a RAP applcation is this:
1) Web Browser --> post event (e.g. button pressed) --> RAP Servlet
2) Web Browser --- waiting for application processing --- RAP Servlet
3) Web Browser <-- receive updates for UI <-- RAP Servlet
So let's say I have a button in my application and a listener that opens
a dialog when it is pressed. Then the above steps translate into: (1)
the button press event is posted to the RAP servlet, (2) the listener is
invoked and calls MessageDialog.openXYZ(), (3) the response tells the
javascript in the browser to draw a dialog box.
Now, when UICallback.activate() is called within the context of step
(2), then the reply sent to the web browser in (3) tells the javascript
to keep the connection open, waiting for further UI update events.
Therefore, the UI in the browser can then be updated without the need
for something to occur in the browser window. Like this:
1) Web Browser --> post event (e.g. button pressed) --> RAP Servlet
2) Web Browser --- UI.callback() is called --- RAP Servlet
3) Web Browser <-- tell browser to expect updates <-- RAP Servlet
4) Web Browser --- keep connection, await further input --- RAP Servlet
5) Web Browser <-- further UI update info delivered <-- RAP Servlet
Therefore, if the button press listener (step 2) starts a thread and
calls UICallback.activate(), then the thread can use
Display.(a)syncExec() to modify the UI of the client and these
modifications are sent to the browser (step 5).
While the "callback mode" is active, the connection is kept open all the
time, therefore UICallback.deactivate() must be issued to release this
resource when you no longer need to push updates (e.g. before the thread
exits).
So, my questions are:
1) what happens if there are 2 threads running on the server that use
Display.(a)syncExec() to modify the UI? do the updates from both get
sent back through the open connection?
2) what is the role of the "id" in the activate/deactivate calls? does
each get assigned its own extra connection to receive UI updates? but
then, how are updates associated with the connections? something else
must be going on.
Frank Appel wrote:
> Hi,
>
> as you already said, the current implementation blocks a request at the
> server-side. In case of Display#syncExec(Runnable) or
> Display#asyncExec(Runnable) called from a serverside background thread,
> this block gets released. The response triggers a standard UI request that
> runs through the normal RWTLifeCycle mechanism. Similarly to SWT there is a
> certain time in the lifecycle (respectively eventloop in SWT) where the
> registered runnables get excecuted.
>
> As always at the end of the RWT lifecycle changes made during request
> processing will be transmitted to the client. In our case the changes are
> performed by the registered runnables.
>
> Last but not least another UICallBack request gets blocked so that in case
> of the next serverside updates the notification of the client can be
> triggered again.
>
>
> Ciao
> Frank
>
>
> "Martin" <mdilger@splitshade.de> schrieb im Newsbeitrag
> news:f03cdde9366b8395fc605498a25ca39e$1@www.eclipse.org...
>> Hi,
>>
>> after I used it several times, I wanted to look at how this
>> UICallBack-Mechanism works, but since there is rare JavaDoc at the moment,
>> I cannot get it completely.
>> How do you do this? As far as I see, you are sending a request to the
>> server, which gets blocked until UI-Updates occur?
>>
>> A word on this would be very much appreciated, thank you.
>>
>> Martin
>>
>
>
|
|
|
| UICallback Mechanism [message #107726 is a reply to message #103332] |
Thu, 02 October 2008 09:57 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
your assumption that in the case of UICallback.activate() the request is
kept alive isn't true. The request cycle is properly processed and
finished on the client side. Instead a second request is opened which
gets blocked at the server. This is only for notifications of the
clientside that the proper UI request is needed in case a
Display.syncExec() for example was called by an background thread on the
server.
Ciao
Frank
-----Ursprüngliche Nachricht-----
Von: Alexandros Karypidis [mailto:akarypid@yahoo.gr]
Bereitgestellt: Donnerstag, 28. August 2008 20:16
Bereitgestellt in: eclipse.technology.rap
Unterhaltung: UICallback Mechanism
Betreff: Re: UICallback Mechanism
I'm also trying to get to grips with the way UICallback works and have
some questions.
My understanding is that the typical lifecycle of a RAP applcation is
this:
1) Web Browser --> post event (e.g. button pressed) --> RAP Servlet
2) Web Browser --- waiting for application processing --- RAP Servlet
3) Web Browser <-- receive updates for UI <-- RAP Servlet
So let's say I have a button in my application and a listener that opens
a dialog when it is pressed. Then the above steps translate into: (1)
the button press event is posted to the RAP servlet, (2) the listener is
invoked and calls MessageDialog.openXYZ(), (3) the response tells the
javascript in the browser to draw a dialog box.
Now, when UICallback.activate() is called within the context of step
(2), then the reply sent to the web browser in (3) tells the javascript
to keep the connection open, waiting for further UI update events.
Therefore, the UI in the browser can then be updated without the need
for something to occur in the browser window. Like this:
1) Web Browser --> post event (e.g. button pressed) --> RAP Servlet
2) Web Browser --- UI.callback() is called --- RAP Servlet
3) Web Browser <-- tell browser to expect updates <-- RAP Servlet
4) Web Browser --- keep connection, await further input --- RAP Servlet
5) Web Browser <-- further UI update info delivered <-- RAP Servlet
Therefore, if the button press listener (step 2) starts a thread and
calls UICallback.activate(), then the thread can use
Display.(a)syncExec() to modify the UI of the client and these
modifications are sent to the browser (step 5).
While the "callback mode" is active, the connection is kept open all the
time, therefore UICallback.deactivate() must be issued to release this
resource when you no longer need to push updates (e.g. before the thread
exits).
So, my questions are:
1) what happens if there are 2 threads running on the server that use
Display.(a)syncExec() to modify the UI? do the updates from both get
sent back through the open connection?
2) what is the role of the "id" in the activate/deactivate calls? does
each get assigned its own extra connection to receive UI updates? but
then, how are updates associated with the connections? something else
must be going on.
Frank Appel wrote:
> Hi,
>
> as you already said, the current implementation blocks a request at
the
> server-side. In case of Display#syncExec(Runnable) or
> Display#asyncExec(Runnable) called from a serverside background
thread,
> this block gets released. The response triggers a standard UI request
that
> runs through the normal RWTLifeCycle mechanism. Similarly to SWT there
is a
> certain time in the lifecycle (respectively eventloop in SWT) where
the
> registered runnables get excecuted.
>
> As always at the end of the RWT lifecycle changes made during request
> processing will be transmitted to the client. In our case the changes
are
> performed by the registered runnables.
>
> Last but not least another UICallBack request gets blocked so that in
case
> of the next serverside updates the notification of the client can be
> triggered again.
>
>
> Ciao
> Frank
>
>
> "Martin" <mdilger@splitshade.de> schrieb im Newsbeitrag
> news:f03cdde9366b8395fc605498a25ca39e$1@www.eclipse.org...
>> Hi,
>>
>> after I used it several times, I wanted to look at how this
>> UICallBack-Mechanism works, but since there is rare JavaDoc at the
moment,
>> I cannot get it completely.
>> How do you do this? As far as I see, you are sending a request to the
>> server, which gets blocked until UI-Updates occur?
>>
>> A word on this would be very much appreciated, thank you.
>>
>> Martin
>>
>
>
|
|
|
Goto Forum:
Current Time: Sun May 11 03:55:24 EDT 2025
Powered by FUDForum. Page generated in 0.02879 seconds |
Home