Springy developers choose DWR

[Antranig Basman]

Hi there Ray - we meet again, at 50,000 feet :P

DWR is fun, although I have to mention (to blow own trumpet, when did anything else)
that we have our homegrown distillation of the technique in the form of RSF's
"Universal View Bus" which I feel is much less intrusive since it functions
with no config files other than Spring ones (no dwr.xml), and similarly no 
extra Java-side artefacts since it just uses the existing application structure. 

Spring Web Flow seems like a winner on paper, but every developer I've exposed
it to in practice becomes highly annoyed. I feel their conception of "flows" is
too restrictive and "top-heavy" (OGNL-driven, and with a meaty RequestContext
object at the other side) to be truly idiomatically portable. I made an 
experimental integration with RSF in the very early days but has languished 
for lack of interest.

Filesystem-previewable templates with behaviour are indeed a reality already :P



Ray Davis wrote:
> 
> DWR = Direct Web Remoting - https://dwr.dev.java.net/
> 
> This looks like magic, and it's being used in production in some
> products (including JIRA and Confluence), but I hadn't heard of it
> until I read this transcription of a talk Bram Smeets gave on "Ajax
> with the Spring Framework":
> 
> http://www.theserverside.com/news/thread.tss?thread_id=44657
> 
> Going over ideas similar to Josh's, he recommends JSON-RPC if you
> want an RPC approach, but recommends DWR even more strongly for
> server-client glue.
> 
> And then I bumped into this, from the lead of Spring Web Flow:
> 
> http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf#view_4214
> 
> "In summary a development team evaluating Spring's web app
> development stack should consider Spring MVC + Web Flow + DWR
> together, and not simply the Spring MVC base in isolation."
> 
> (I look forward to seeing how much of Spring MVC we could eliminate
> from that combination.)
> 
> The DWR 2 preview examples are getting to a spot in which we could
> create fully interactive browser-only (no server) prototypes
> populated with test data by JavaScript. And then after some initial
> user testing's been done, we could replace the JavaScript-loaded test
> data bit by bit with dynamic server-based data without touching the
> "prototype's" XHTML or CSS.... Specifications which double as
> production code. It's a nice dream.