- From: Flinton Adam <Adam.Flinton@cfh.nhs.uk>
- Date: Mon, 7 Nov 2005 12:41:55 -0000
- 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 UTC