Help us choose the right UI framework

To over-summarize, over the last 5 years we have built an open source Electronic Medical Record framework (OpenMRS.org) aimed at developing countries. It's popular (in use in 20+ countries, from Haiti, to Kenya, to India) and customizable (70 modules in our repository), and we're happy with our data model, our API, and our vibrant community. We're much less happy with the state of our user interface, and we see ourselves having a one-time-only chance to rewrite a much better user interface from scratch. Therefore we also have a chance to choose a new UI framework/platform/stack that will give us a better end-product and an easier and more efficient development cycle.

Since this is a one-time-only opportunity, we want to pick the best possible framework. Any suggestions/discussions/feedback about this are extremely valuable to our community.

I. Specific Requirements and Criteria

Web application or RIA

Must support Linux and Windows as server platforms. Client needs to run in a vanilla browser with no extra software or plugins.

We're rewriting the UI, but keeping our existing Java API.

Whatever framework we choose, it has to be able to import our openmrs-api.jar, which is a Spring app. (About to be Spring 3.0.) So anything that can't use a Java back-end is disqualified. (Using web services to get around this is probably okay.)

We need to support modules that add UI- and API-layer functionality

Our app is heavily customizable, with a custom module framework. We eventually want to be OSGi-compatible, but we aren't there yet. In the UI layer, a module needs to be able to do the following (or their equivalents in a RIA):
add a link to an existing list of links (e.g. add a link to the top-level nav bar)
add content to a page (e.g. add another tab to the patient dashboard)
override a url (e.g. replace the default createPatient.form page)
Anything that can't add a new module without recompilation is disqualified.

Reusable components

We need to build the new UI out of reusable components (e.g. "patient search widget", "table of visits of a particular encounter_type", ...) If we do this right it becomes trivially easy for people to write modules or completely new UIs that use the OpenMRS platform to do 1000 things we haven't. (Personal health record, clinical trial management, teaching tool, etc.) Bonus points for any framework that makes writing components easy, but we'll roll-our-own if required.

Writing code is easy and fun

Rapid prototyping, Dynamic recompilation, Convention-over-configuration, and DRY are all wonderful things.

Accessible to entry-level coders

Our developer community has widely-varying levels of training. We want people who have had poor formal programming education (maybe they learned visual basic in university) to be able to write modules that provide useful customizations to their local OpenMRS installations. Getting low-level coders to be effective is more valuable to us that allowing high-level coders to be ultra-effective. (Having high-level coders write generalizable tools so that low-level coders are just customizing that is a possible approach.)

Works over slow internet connections

A significant minority of OpenMRS installations are run over slow internet connections, including satellites. Too much ajax can be a bad thing. (Specifically, when you have good bandwidth but high latency, downloading 3 tiny pieces of json can take longer than loading a whole page.) This isn't the primary consideration, but the app can't be unusable over a satellite.

Support for testing

Bonus points for any framework that makes it easy to write UI-layer tests. (>95% of our existing tests are API-level unit tests.)

Well-supported

We don't want to end up using a framework that's really cool today, and gets abandoned in a year.

Scalable

Currently a "very large" OpenMRS installation would be 30 simultaneous users, 500k patients and 50M observations. Two years from now we need to support 10x that. Whatever framework we choose needs to scale. Bonus points for a platform that is easy to run on clustered hardware. Cloud could work too, but is non-ideal: the current biggest installation is on a LAN in Haiti that doesn't (can't) have a fast uplink.

II. (Some) options

Here are some of the options we're considering. (We haven't done full due diligence about whether all of these will support our modular architecture.) Our plan is take the ~5 most promising frameworks and have a bake-of, i.e. implement one illustrative example in each of them, and let the community play around with them, look at the code required, before making a decision.

• Spring MVC + some js toolkit (EXT JS, YUI, JQuery, ...)

• Grails + some js toolkit

• JSF + ICEfaces

• GXT

• JSR-168: make our app a portal container and let people write portlets in whatever technology they want. We'll still build our UI in one of the above stacks.

• (Honorable mentions, unlikely to make the short list: Wicket, ZK)

So, my question for you all is: are any of these particularly good or bad ideas? Have we missed any good alternatives? We're trying to optimize over a lot conflicting constraints, so informed opinions are gold.