Web Presentation digest

[Ray Davis]

For those on the "Dev Team" track, here's my outline for the 
discussion starter I'd planned tomorrow. It's clipped, but I'm fairly 
certain you can all read PowerPointese. At any rate, if you want five 
or more minutes of blather on any bullet point, just drop a nickel in 
the slot. The conclusion is a request for guidance as far as where I 
or other researchers should focus our efforts.

Thanks for reading & responding,
Ray

===

Java Web Presentation Technologies and Fluid

===

Overview

* The special case of DWR
* Overview of Java web presentation approaches
* How do they fit with Fluid's goals?
* Menu of possible "next steps"

===

DWR

Integrate pure AJAX, pure HTML, and pure Java services

# Add one JAR to Maven dependencies
# Minimal configuration to say which Spring beans and methods are 
exposed to JavaScript
# Add one JavaScript include line to the HTML file for each bean

Result : Spring bean methods become generic asynchronous JavaScript 
functions with callbacks

Very satisfying unless you need server-generated HTML.

===

Why does Java have problems with the web?

As compared to C++, C, Basic, Smalltalk, COBOL, ...?
Beaten by light-weight scripting and dynamically-typed languages: 
Perl, PHP, Ruby-on-Rails

===

Reactions

JSP Antica : HTML + Embedded Java + Configuration
"No, Java really _isn't_ a dynamic scripting language"

JSP Nouveau : HTML + Embedded non-Java Expression Language + Embedded 
non-HTML tags + Java + Configuration
Ubiquitous, stable, and flexible.

===

HTML-embedded EL + Non-HTML tags + Java + Configuration

* JSF
* JSP + various server-side helpers (Spring MVC)
* Facelets + JSF = close enough to HTML to scrape by?
* Tapestry = good HTML previews; idiosyncratic and risky

===

The revolution: HTML with no embedded EL

* Wicket = HTML + Java
* RSF = HTML + Java + Configuration + Property reference strings

===

Upsides of revolution

* Cleaner match of human duties to files
* Fewer idiosyncrasies to learn, track, and produce support tools for

===

Downsides of revolution

* Wordier
* Tight conceptual coupling between template and Java, but no automated support
* Hides some important UI aspects from the template (notably conditionals)

===

Fluid's split goals

* Guide and support quickly-moving user-centered projects
* Deliver Fluid projects

===

Fluid requirements for presentation technologies

* User-centered design
- Request-based work flows (back-button, multiple active contexts)
- Bookmarkable
- Able to replicate any HTML + JS

* Faster project delivery
- Shorten mock-up / delivery turnaround time, preferably with 
browser-previewable templates
- Easy integration with Spring

===

Don't meet requirements

* JSF 1.1
* Early Tapestry
* Early Wicket

===

Possibly meet requirements

* Tapestry now
* Wicket now
* Facelets + JSF 1.2

===

The revolutionaries

Wicket and RSF share the most characteristics. Programmers who refuse 
to use one will probably refuse to use the other.
Wicket is a well-run project with a small but fervent community.

RSF is unique among all these frameworks in having the following 
goals *pre-1.0*:

* Request-based work flows
* Bookmarkable
* Able to replicate any HTML + JS
* Previewable HTML
* Easy integration with Spring
* Working with user interaction / design / accessibility communities

===

Next steps? Priorities? Personnel assignment?

* RE: Guide and support quickly-moving user-centered projects

- Put DWR on the approved list?
- Check for problems with JSP 2, Facelets, Tapestry, Wicket, etc.?
OR wait for volunteers or requests from experts in those technologies?
- Spread use of Fluid-developed or approved components in projects 
using any viable technology?

* RE: Deliver Fluid projects

- Take advantage of the unique "ground floor" opportunity presented by RSF