| Evaluating RAP [message #110419] |
Fri, 24 October 2008 04:17  |
 Walter Rumsby
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  |
Eclipse User |
|
|
|
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 #110583 is a reply to message #110562] |
Mon, 27 October 2008 21:57 |
| Eclipse User |
|
|
|
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 |
| Eclipse User |
|
|
|
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 |
Stefan Hansel
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
|
|
|
Powered by
FUDForum. Page generated in 0.04295 seconds
] 
Search
Help
Register
Login
Home
