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

RE: Is or isn't scripting needed, was RE: XForms vs. Web Forms

From: Dharmesh Mistry <Dharmesh.Mistry@edgeipk.com>
Date: Wed, 16 Mar 2005 22:22:15 -0000
Message-ID: <6E80CFEBE068F44BAD79EB89CA1FD5910704C4@edgemail01.uk.edgeipk.com>
To: "Eric S. Fisher" <efisher@fsystems.com>, <www-forms@w3.org>
 
Eric>If you can't be sure a form 
>submission will come in with the same level of validation every time, you 
>then must code your server side either to test for the presence of the 
>validation facilities in the browser (more code) or not trust the client 
>side validations and repeat them at the server side (more code, but 
>required anyway if the above test fails).

Dharmesh>In secure e-commerce applications you can't trust what the client sends back so you have to re-validate the client data. With open source browsers and packet sniffers, change data going back to the server after it has left the "client" is possible, so server side validation is mandatory.
 
Hence here is one of those "real life" issues I don't think has been thought about when people talk about client side technologies. The advantage of server side form generation is that validation used to send to the client can also be re-executed by the server.
 
 
Also talk about script incompatibilities across browsers raises the issue that standards are in place but it is the vendors who "extend" them.........JavaScript, ECMAScript. So the questions is if plug-ins are all purely standard how do they compete as products?
 
Macromedia say that they plug-in is in over 80% of browsers, Java a similar amount, PDF......What percentage has XForms. Don't get me wrong, I'd prefer 1 standards based technology, but as a software company we need to be commercial about placing bets on technology.
 

________________________________

From: www-forms-request@w3.org on behalf of Eric S. Fisher
Sent: Wed 3/16/2005 8:31 PM
To: www-forms@w3.org
Subject: Re: Is or isn't scripting needed, was RE: XForms vs. Web Forms




First, apologies to Christopher Goodrich for implying that plug-ins were 
always easy enough to use and install to be an acceptable option.  The 
references to Macromedia, etc., were mine and had nothing to do with the 
article's content.  I haven't stood help desk duty for over 35 years, and 
back then I was helping people debug FORTRAN programs.  I guess I'm a 
little out of touch :)

But I have to ask the question: Isn't a well-designed, open-source plug-in 
an acceptable method for providing browser functionality for technologies 
not available when the browser was released?  I may have chosen bad 
examples due to my own ignorance, but it seems to me that bad examples 
don't necessarily invalidate an assertion.  And there appear to be XForms 
plug-ins available for every major browser.

Second, the more I follow this discussion, the more confused I get.  WF2 
is supposed to be backward compatible, yet to use its full functionality, 
you need a new browser or yet another plug-in?  How is that preferable to 
a clean, fresh XForms implementation?  Especially considering that any 
"new browser" will always support the old code anyway?

And what use is it to be able to display a form and not have the 
client-side validation work properly?  If you can't be sure a form 
submission will come in with the same level of validation every time, you 
then must code your server side either to test for the presence of the 
validation facilities in the browser (more code) or not trust the client 
side validations and repeat them at the server side (more code, but 
required anyway if the above test fails).

I'm sorry, but the more I hear about WF2 the less I like it.

Eric S. Fisher

On Wed, 16 Mar 2005 19:41:25 +0100, Anne van Kesteren 
<fora@annevankesteren.nl> wrote:

>
> John Boyer wrote:
>> This is curious to me. If not with a pile of javascript, then can you
>> explain how else the new attributes and their values will be given
>> meaning other than by a browser upgrade?
>
> I thought we were comparing "native implementations". If you want to 
> implement WF2 in a curernt browser, then yes, you need scripting. 
> However, you could create a plugin as well, as is done for XForms.
>
>
>> Without scripting, isn't it the case that the WHAT-WG is no more 
>> compatible with IE and other existing browsers than XForms?
>
> Not really. Where IE would download a page using XForms embedded in 
> XHTML it would show a page using WF2 in HTML. Also, the form can still 
> be submitted, but client-side validation is lost.
>
>
>> With scripting, isn't it true that existing browsers can be used for
>> the WHAT-WG proposal?  But isn't it also true that with scripting the
>> existing browsers can be used to support XForms?
>
> The first is true. The second is false. IE doesn't support the 
> 'application/xhtml+xml' namespace, for example.
>
>



--
Important Note:  This e-mail may contain trade secrets or privileged, 
undisclosed or otherwise confidential information.  If you have received 
this e-mail in error, you are hereby notified that any review, copying, or 
distribution of it is strictly prohibited.  Please inform me immediately 
and destroy the original transmittal.  Thank you for your cooperation.
Received on Wednesday, 16 March 2005 22:22:18 GMT

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