RE: xforms processors

Thanks for this informative feedback. 

As per our requirements there should not be any client side installation. 

So that is one more reason i am going for server side xform processor. 

Regards,
Jagan.

-----Original Message-----
From: Mark Birbeck [mailto:Mark.Birbeck@x-port.net]
Sent: Tuesday, July 01, 2003 2:04 PM
To: Jagannayakam
Cc: www-forms@w3.org
Subject: RE: xforms processors


Hello Jagannayakam,

> I think Forms player works as a renderer . To display a html form that has
> xform tags. But if the user updates something and submits again the
> request goes in the form of name&value pairs am i right .

No. FormsPlayer is a proper client-side implementation of the XForms spec,
but it just happens to 'run' inside Internet Explorer. So what FormsPlayer
submits will be whatever the form you have designed tells it to submit. Take
a look at the XForms specification, and also look at the samples on our site
(http://www.FormsPlayer.com/).
 
> For me i have to talk to xml inteface. So there should be a processor on
> the client side that changes these name values pair to xml . Thus requires
> a processor in the server side.

That is not at all what XForms is all about. You want to deal with XML all
the way through, so that you can use schemas, namespaces, hierarchy, and so
on. There is a lot more to it than just transposing name/value pairs into an
XML document.

> So when we have a server side processor  there is no seperate need of a
> client side processor.

This is something that has been much discussed on this list, and IMO much
misunderstood. The basis of the misunderstanding is that there is no 'one
size fits all' solution.

Obviously the architecture of an XForms processor should be built as a
client/server application, since that is good programming practice. But the
question is where should the different pieces be situated?

If we see an XForms processor as comprising data, a UI and a controller to
control the interaction between these two pieces, there are a number of
scenarios that we could adopt:

1. The client has all three layers. This is ideal for powerful PCs where we
want to get the full range of functionality and a fast experience for the
user. It will usually require a one-off install though - such as a player or
a new browser.

2. The server has both the data and the controller, and the user has a very
thin UI using a web browser. This approach is ideal for small legacy
devices, such as mobile phones with WML.
 
3. The server has a data and part of the controller, and the client PC has a
sub-set of the data, the remaining parts of the controller, and the UI. This
is optimal for situations where a client install is not possible, but the
client device is capable of more functionality than a simple phone. This
approach can dramatically reduce round-trips to the server over option 2.

Whilst it is the case that a very quick way of getting an XForms processor
up and running is to take option 2, I feel it will ultimately be options 1
and 3 that become predominant - mainly for reasons of interoperability.
(Option 3 is the approach we are taking with our server-side
implementation.)

I hope this helps.

Regards,

Mark


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

Download our XForms processor for IE
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 Tuesday, 1 July 2003 07:11:49 UTC