W3C home > Mailing lists > Public > www-forms@w3.org > November 2005

RE: AJAX vs. Xforms

From: Flinton Adam <Adam.Flinton@cfh.nhs.uk>
Date: Mon, 7 Nov 2005 12:41:55 -0000
Message-ID: <595299DD7F30014BBCE48B93DCB6065203312FEB@EXCHAQ2.nhsia.nhs.uk>
To: <jeacott@hardlight.com.au>
CC: <www-forms@w3.org>

Xforms on the client side does make for a very useful low cost, easy to
implement (assuming the problems I have detailed are dealt with) way of
rendering a piece of XML into a human readable/editable form. I accept
that there are limitations vs. running it against a server where you can
add in all sorts of nice stuff e.g. database/datastore access,
authentication etc.etc.

Adam 

> -----Original Message-----
> From: Jason Eacott [mailto:jeacott@hardlight.com.au] 
> Sent: 07 November 2005 11:00
> To: Flinton Adam
> Cc: www-forms@w3.org
> Subject: RE: AJAX vs. Xforms
> 
> > For what it's worth, I don't include Chiba and Orbeon in 
> this class. 
> > Those I haven't used. I think those projects have problems too, but 
> > they're of a different nature. I'm not convinced of the 
> feasibility, 
> > usability, or maintainability of a primarily server-side 
> solution; but 
> > that's an argument for another thread.
> > 
> 
> I've said this before,
> 	I'm not convinced of the feasibility, useability, 
> maintainability or security of clientside solutions.
> 
> I think clientside Xforms has a serious problem with keeping secrets.
> HTML forms are incapable of sending emails by themselves (and 
> many other functions), and where they require secrets to be 
> kept from the client they need lots of help, usually by means 
> of serverside function. 
> If I want my Xform Submission to send an email then I have to 
> include that/those email address(es) in the Xform!, If I dont 
> then I'd have to code it as a completely separate serverside 
> function and thats not what Xforms is about. What about a 
> case where I need to send a username and/or password to 
> retreive data from a 3rd party? (perhaps the isp for example 
> holds a subscription to some content service and it can only 
> be accessed by supplying user/pass - but that information 
> should NOT be revealed to the user of the form.) With a 100% 
> clientside implementation I think this is impossible.
> With a serverside Xform implementation at least I can use 
> Xforms as it was intended with all its functionality in tact 
> without the huge security issues potentially associated with 
> sending too much data to the client.
> This is the reason I think that the current serverside 
> implementations that people are describing as a stop gap 
> measure until Xforms becomes ubiquitous amongst the big 
> browsers will be around a lot longer than that.
> 
> its just my opinion, but I think these are big problems with 
> using a 100% clientside solution in many cases. I can however 
> also see cases where having the option to run clientside 
> would be helpful - when the server isnt available for example.
> It would be helpful sometimes to be able to pick and choose 
> which parts of a forms models and views were suitable for 
> 100% client only processing and those which should never be 
> used by the client directly.
> 
> my 2 cents
> Jason.
> 
> 
> 
> 	
> 

This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation.
Received on Monday, 7 November 2005 12:58:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:02 GMT