Springy developers choose DWR

[antranig at caret.cam.ac.uk]

Replying to Colin and Ray:

Quoting Colin Clark <colin.clark at utoronto.ca>:

> Hi Ray and Antranig,
>
> We're planning to dig into DWR a bit more in the next little while,
> and I'm also interested to hear how your own research goes. I've
> heard very good reviews of it, although my one concern was the fact
> that it's rather closely bound to Java running on the server side.
> Integration with non-Java applications is not a deliverable in the
> initial 2 years of the project, but as much as possible I'd like to
> emphasize loose-coupling between the client side and the whatever
> language is running on the server.

Yes well, a port of RSF to PHP is something that I have been slightly
more than semi-seriously promoting to people :P Certainly I think we
would have more luck than with DWR which is *clearly* Java-bound - it
is Java-side code that fabricates the JS lumps after all. I believe
"in theory" one could wrote code processing RSF binding fairly easily
in any language on the server-side. I have some half-cracked idea for
"compiling" Spring contexts into native PHP contexts also... as you say,
not a near-term deliverable.

> Antranig, do you want to provide us with a bit of an overview of the
> Universal View Bus?
>
> Colin

> Had a feeling I'd be hearing from you on this one, Antranig!  :)  I
> hope I can get a chance for a Real Life compare-and-contrast of the
> two approaches sometime soon. As a naive consumer of propaganda from
> both sides, I should keep my mouth shut till I get my hands dirty....

> I'd gotten the impression that Spring Web Flow developers were
> generally a happy lot, so I had been wondering what was up with the
> RSF integration. On paper, they do seem complementary. I admit,
> though, it's been a while since anyone's done programming on paper.

> BTW, DWR + Spring configuration is another thing that seems to have
> improved in DWR recently (not too surprising, given the Spring
> opinions I cited). You might want to give it another look.
Ray

OK, read up on the new Spring 2-schema driven stuff.

I don't doubt that DWR(2) + Spring is really quite slick, but it
could never really be as slick as doing nothing at all. The "secret"
fact is that RSF form submissions have always proceeded by a DWR-like
scheme since day 1, and so support for this kind of "direct remoting"
idiom is just a matter of defining what kind of form you want the
AJAX response to take. The "UVBView.xml" (around 4 lines of XML and 30
of Java) is just one, admittedly tolerably universal possibility.
Where there is room for more work with UVB is in the serialization
of complex objects, which currently would be done into XML.

In terms of Colin's request for a general overview, the point to
bear in mind is that an RSF form consists of a "minimally annotated"
absolutely standard HTML form. The minimal annotations take the form
of a set of hidden fields of various simple forms (I have already
written client-side code to parse these as part of rsf.js) which
explain the mapping of the form controls to named parts of the
server-side request model. This naming is done via RSF EL, which is
just a set of named bean paths.

So when I see client-side artefacts like this:

<script type='text/javascript'
xsrc='/dwrPath/interface/productManager.js’></script>
<script type=’text/javascript’ xsrc=’/dwrPath/engine.js’></script>

I worry somewhat since this represents coupling to a particular
framework and application structure. Note that this isn't just a
single static framework js file, but a particular synthesized one
derived dynamically from the application structure. Who knows what's
in it!

Similarly at the top end, we have dwr-dependence in the app schema:
 <dwr:remote javascript="SampleBean"/>

>From *my* view, all of these approaches to the problem, all separately
admirable suffer from the problem that they are all rather fragmentary.
DWR defines no particular rendering model, SpringMVC defines no
particular application representation, and has even less to say about
URL structure. It's very easy to "cobble together" the bits of them
so they work moderately well, but the resulting structure always has
undesirably unnavigable dependencies sticking out of the sides, and
could never work as well as a system that was designed to operate
harmoniously from the start. Oh well, no point carrying on thumping
the tub :P

My view when making RSF was for every part of it to represent the
minimum intrusion on its environment, and yet represent a complete
end-to-end "idiom" that makes everyone's responsibilities clear.
It's perhaps "semi-"incidental that this ended up pushing lots of
"standard" desirable conceptions to the forefront (RESTful
URL structures, plain HTML, strong use of IoC), but somewhat hard
to say!


Will you be able to drop in on the video-conference tomorrow, Ray?

Cheers,
A.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.