RE: XForms Client versus Server

Steve,

> I would have thought that any implementation that relies on round trips to
> a server will not be XForms compliant unless the server is contacted every
> time the value of a control is altered.

That doesn't follow. Of course you could do it that way, but you could do it
any number of other ways, too.

> The reason is that the form is required to behave as though it is directly
> linked to the underlying XML document.

But as you say, it is only required to behave "as though" it is connected.
Provided the functionality specified in the XForms spec is adhered to, it
doesn't matter how it is achieved.

> That means that, if more than one control is linked to a particular
> element, changing one should immediately change the other.  The
> same logic applies to calculations using XPath.

Sure ... but even simple DHTML can do that. The real challenge is to work
out "when" to go back to the server, rather than going every time, for every
event.

In fact, given the events-based architecture of XForms, you could actually
'split' an XForms form across two or three servers, and the client PC ...
and still be conforming to the standard!

> I can't see a way round this.  For example, if two controls are linked to
> a single element, and the client can't deal with this, how should the
> server interpret the contradictory data sent to it?

That would of course be a problem, so you have to make sure you return
unambiguous data.
 
Regards,

Mark


Mark Birbeck
Co-author Professional XML and
Professional XML Meta Data,
both by Wrox Press

Download our XForms processor for IE 6
from http://www.FormsPlayer.com/

Managing Director
x-port.net Ltd.
4 Pear Tree Court
London
EC1R 0DS

E: Mark.Birbeck@x-port.net
W: www.x-port.net
T: +44 (20) 7689 9232

Received on Friday, 25 July 2003 07:30:16 UTC