Re: xforms processors

Mark,

excellent analysis of the problem.

Mark Birbeck wrote:
> 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.)

Absolutely agree with these points - with a small addition

IMO only option 3 is really flexible enough for real applications cause 
option 1 lacks the possibility of server-side validation. (ok, setting 
aside that there might be some non-networked apps which don't even need 
that)

'no size fits all', so there's room for a lot of different approaches 
each of which may have their relevance for a particular project. option 
3 just offers the most flexibility to fit the different cases.

Regards

Joern Turner



> 
> 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 11:10:41 UTC