Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Remote Application Platform (RAP) » Evaluating RAP
Evaluating RAP [message #110419] Fri, 24 October 2008 04:17 Go to next message
Walter Rumsby is currently offline Walter RumsbyFriend
Messages: 7
Registered: July 2009
Junior Member
Hi There,

I'm part of a team evaluating RAP as a solution for the UI of our product
suite. I'm familiar with action-based Java web frameworks and JavaScript
(primarily YUI) and I have some questions about RAP that I would like to
ask the newsgroup as part of my evaluation:

1. As it is currently implemented RAP is quite chatty which makes me
wonder about the impact on [perceived] performance in network environments
with significant latency. Some of our customers deploy across large
regional areas (i.e. not simply within a single office network or even
within the same city) so latency can be a problem here. Specifically:

* Are there other RAP deployments that have successfully dealt with
solutions deployed across a large geographic area (i.e. greater than
100,000 km^2)?
* Would it be possible for future versions of RAP to allow solutions to
optimise at least some of the processing of selection listeners to process
frequently selected elements on the client (i.e. without the need for an
XHR)?
* If the above is not possible are there alternative approaches that could
be applied to improve perceived performance (e.g. change the UI to the
expected result state, perform an XHR and handle any differences to the
expected state when the callback returns)?

2. The default theme uses inline styles extensively. It also relies on
styled elements rather than default controls for things like checkboxes.
Could alternative themes choose not to use inline styles or to use native
controls? Have issues like accessibility and automated testing (of the UI,
e.g. using something like WATFO, Canoo WebTest, etc.) been considered?

3. Finally, it appears that every request is routed through a single URL.
This raises potential issues around how browsers might choose to cache
content, how easily filters and interceptors that map to url-mappings,
etc. can be applied. Has this presented itself as an issue and/or have
people worked around this?

Regards,
Walter
Re: Evaluating RAP [message #110467 is a reply to message #110419] Fri, 24 October 2008 10:47 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: mike.xmos.com

My 2 cents with regard to rolling out RAP applications:

Latency doesn't seem to be an issue unless you're using HTTPS - we have
a server in the UK and responsiveness from the states is fine (with
HTTPS I think you double the round trip time for every button click
because of the connection handshaking which is a bit of an issue).

The main problem we've found is updates - because RAP sessions are
stored in memory rather than on a database, if you take a server down
for an update then you will kill every session on that server. I'm not
aware of any way to avoid this other than implementing some fancy
mechanism which redirects new sessions to a second server before an
update, waits until all existing sessions timeout on the original server
(which could be impossible if someone keeps clicking things!) doing the
update, then putting it back online.

Mike


Walter Rumsby wrote:
> Hi There,
>
> I'm part of a team evaluating RAP as a solution for the UI of our
> product suite. I'm familiar with action-based Java web frameworks and
> JavaScript (primarily YUI) and I have some questions about RAP that I
> would like to ask the newsgroup as part of my evaluation:
>
> 1. As it is currently implemented RAP is quite chatty which makes me
> wonder about the impact on [perceived] performance in network
> environments with significant latency. Some of our customers deploy
> across large regional areas (i.e. not simply within a single office
> network or even within the same city) so latency can be a problem here.
> Specifically:
>
> * Are there other RAP deployments that have successfully dealt with
> solutions deployed across a large geographic area (i.e. greater than
> 100,000 km^2)?
> * Would it be possible for future versions of RAP to allow solutions to
> optimise at least some of the processing of selection listeners to
> process frequently selected elements on the client (i.e. without the
> need for an XHR)?
> * If the above is not possible are there alternative approaches that
> could be applied to improve perceived performance (e.g. change the UI to
> the expected result state, perform an XHR and handle any differences to
> the expected state when the callback returns)?
>
> 2. The default theme uses inline styles extensively. It also relies on
> styled elements rather than default controls for things like checkboxes.
> Could alternative themes choose not to use inline styles or to use
> native controls? Have issues like accessibility and automated testing
> (of the UI, e.g. using something like WATFO, Canoo WebTest, etc.) been
> considered?
>
> 3. Finally, it appears that every request is routed through a single
> URL. This raises potential issues around how browsers might choose to
> cache content, how easily filters and interceptors that map to
> url-mappings, etc. can be applied. Has this presented itself as an issue
> and/or have people worked around this?
>
> Regards,
> Walter
>
Re: Evaluating RAP [message #110514 is a reply to message #110419] Mon, 27 October 2008 09:47 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rsternberg.innoopract.com

Hi Walter,

> 2. The default theme uses inline styles extensively. It also relies on
> styled elements rather than default controls for things like checkboxes.
> Could alternative themes choose not to use inline styles or to use
> native controls?

I guess with "inline styles" you refer to the use of "style" attributes
in the DOM elements instead of a central style sheet. There are
different reasons for this approach, they are summed up in this FAQ:
http://wiki.eclipse.org/RAP/FAQ#Why_doesn.27t_RAP_simply_use _CSS_for_styling.2C_such_as_e.g._GWT.3F

For checkboxes and radiobuttons, we currently use native widgets, but we
will change this, as the native look interferes with custom themes. See
bug 250160: [Button] Implement RADIO Buttons using images
https://bugs.eclipse.org/bugs/show_bug.cgi?id=250160


Best regards, Ralf
Re: Evaluating RAP [message #110551 is a reply to message #110514] Mon, 27 October 2008 20:13 Go to previous messageGo to next message
Walter Rumsby is currently offline Walter RumsbyFriend
Messages: 7
Registered: July 2009
Junior Member
Ralf Sternberg wrote:

> For checkboxes and radiobuttons, we currently use native widgets, but we
> will change this, as the native look interferes with custom themes. See
> bug 250160: [Button] Implement RADIO Buttons using images
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=250160

I was looking at a tree example that included checkboxes implemented using
images and I assumed that all checkboxes would be implememnted as images,
which appears not to be the case.

However, if bug 250160 is resolved does this mean that images will
*always* be used, or just in cases where themes are applied?
Re: Evaluating RAP [message #110562 is a reply to message #110419] Mon, 27 October 2008 20:39 Go to previous messageGo to next message
Walter Rumsby is currently offline Walter RumsbyFriend
Messages: 7
Registered: July 2009
Junior Member
One thing that particularly interests me is the way event processing is
handled by the server. Would it not be possible to do all (or at least the
majority) of the server-side processing on the client instead? This would
involve an architectural change, but would possibly lead to a more
performant solution:

* qooxdoo already provides an eventing system that works in the browser
(AFAIK qooxdoo supports custom events as implemented JavaScript/AJAX
libraries)
* adding client-side event handling would obviously require additional
JavaScript to be sent to the browser, but much of this could be cached so
initial page load should be about the same
* handling events without requiring a roundtrip to the server is going to
save time and require less work from the server (which should also help
with scalability)

The server-side event processing approach is one that many libraries
appear to favour, particularly those which provide a Java API to create
UIs, but I've always wondered why they chose to do event processing on the
server rather than on the client. I'd really appreciate it if somebody
could expand on this decision.

Regards,
Walter
Re: Evaluating RAP [message #110574 is a reply to message #110419] Mon, 27 October 2008 21:34 Go to previous messageGo to next message
Walter Rumsby is currently offline Walter RumsbyFriend
Messages: 7
Registered: July 2009
Junior Member
Walter Rumsby wrote:

> e.g. using something like WATFO, Canoo WebTest, etc.) been considered?

Correction, this should read "something like Watir, Canoo WebTest, etc."
Re: Evaluating RAP [message #110583 is a reply to message #110562] Mon, 27 October 2008 21:57 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rsternberg.innoopract.com

Hi Walter,

the focus of RAP is to allow "single sourcing" with RCP applications.
Developers should be able to run existing applications without major
rewriting. This is almost impossible to achieve with a client-side event
processing model.

As an example, what if the processing of an event needs database access?
The developer would at least need to distinguish events that need the
server side from those that do not and probably do a lot of RPC plumbing.

With regard to performance, the hardest problems for us to cope with are
related to the capabilities of today's browsers. This would hardly get
better with doing more processing on the client.

Best regards, Ralf

Walter Rumsby wrote:
> One thing that particularly interests me is the way event processing is
> handled by the server. Would it not be possible to do all (or at least
> the majority) of the server-side processing on the client instead? This
> would involve an architectural change, but would possibly lead to a more
> performant solution:
>
> * qooxdoo already provides an eventing system that works in the browser
> (AFAIK qooxdoo supports custom events as implemented JavaScript/AJAX
> libraries)
> * adding client-side event handling would obviously require additional
> JavaScript to be sent to the browser, but much of this could be cached
> so initial page load should be about the same
> * handling events without requiring a roundtrip to the server is going
> to save time and require less work from the server (which should also
> help with scalability)
>
> The server-side event processing approach is one that many libraries
> appear to favour, particularly those which provide a Java API to create
> UIs, but I've always wondered why they chose to do event processing on
> the server rather than on the client. I'd really appreciate it if
> somebody could expand on this decision.
>
> Regards,
> Walter
>
Re: Evaluating RAP [message #110607 is a reply to message #110551] Tue, 28 October 2008 09:05 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: rsternberg.innoopract.com

Walter Rumsby wrote:
> However, if bug 250160 is resolved does this mean that images will
> *always* be used, or just in cases where themes are applied?

Always.

Ralf
Re: Evaluating RAP [message #110670 is a reply to message #110419] Tue, 28 October 2008 20:41 Go to previous message
Stefan Hansel is currently offline Stefan HanselFriend
Messages: 103
Registered: July 2009
Senior Member
>> Have issues like accessibility and automated testing (of the UI,
>> e.g. using something like WATFO, Canoo WebTest, etc.) been considered?

Coming from the desktop-world we have good experience in testing
Swing-Applications with the abbot-framework.
With abbot it is also possible to test SWT-apps (likewise with any other
framework on the market).

Given that from my knowing there is no 'official' way to do RAP-webtests,
we decided to use abbot.swt to automatically test most of our
GUI-behaviour-related functionality in our (single-sourced)-SWT/RAP
application.
Those test are more straightforward to write in java anyway and we achieve
an average automated test-coverage of 80% GUI-code this way.

This setup of course relies on some assumptions, most notably:
- we heavily rely on RAP to have no bugs, when bringing our app the web :D

This is of course verified while developing and with some final manual
web-tests on each iteration.


For further improvement and reliablity we prototyped web-tests with
Selenium. This worked good so far (using the Selenium-Qooxdoo-Extension
available on the qooxdoo-webpage).
There are some issues with timing (e.g. robustly waiting for
rwt-ajax-request to return, instead of just waiting some milliseconds
before each click) which we were able to solve (but some deeper qooxdoo
and RWT javascript knowledge is needed for that).

Next steps involve to write a thin Java-Layer around those
'robust-waiting'-functions.
Furthermore we think of writing a thin Java-Layer for easy finding of
elements which we want to click/test, as we know it from abbot.
This layers will hopefully ease the use of Selenium in our webtests and
hide the difficulties from the actual test-writers.

Regards,
Stefan
Previous Topic:Approach towards Login-Authorization functionality
Next Topic:Hyperlink does not wrap
Goto Forum:
  


Current Time: Sat Feb 04 23:24:11 GMT 2023

Powered by FUDForum. Page generated in 0.07709 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top