Somehow my original response to this went into a black hole. "L. David Baron" <[EMAIL PROTECTED]> wrote in message > On Tuesday 2004-04-27 21:07 -0700, Bryan W. Taylor wrote: > > your targetting XML format. You also have to do validations that could > > be done on the client and that means crummy performance. XForms is > > Validation needs to be done on the server anyway. Promoting > client-side-only validation will just lead people to write lots of > security holes into their server software.
This is wrong for three reasons: 1) you wrongly assume users are always untrusted A security hole is defined as allowing, intentionally or otherwise, a user to have access to a resource reserved for a higher trust level. In an enterprise system, you often will require trusted users even for read access. This can be enforced via a mix of authentication, firewalls, logging, encryption and general policy. So if I have an inventory system and I've profided an XForm to allow my materials planner to review and change the "number in stock" field, I don't have to worry about the person circumventing my validations using perl and entering a negative number any more than I have to worry about them fabricating the number and putting the bad data in the system through the front door. 2) you changed my phrasing "validations that could be done on the client" into "client-side-only". Validation often occurs in an edit-validate-repeat loop. Performance is optimized when the number of these validations that occur on the server is minimized. If I have trusted users, I might be able to minimize it to zero. If not, I expect to minimize it to one validation. Each server-side validation above this requires needless round-trips to the client and wasted computation using the server's resources. 3) You wrongly assume that a mix of client and server side validations is not the easiest to develop. The complexity in validation is usually in the error handling and flow control. When I know I'm trying to do validation on the client and I see a server side validation error, then I know I've either got an attack or I've got a bug. In either case, the response is trivial: I abort and log everything and tell the user "sorry, your submission failed -- contact your administrator". When I do client validation in response to data entry events, the user is getting real-time feedback that is inherently much more nuanced. If I don't have client side validation, I may have to write a lot of gnarly code that has to identify and respond to different failure modes without the benefit of seeing the user events as they occur. This information loss can sometimes make the cause of the error undeterminable. And something to the effect of "The checkbook doesn't balance" is all you can say. In fact, that freedom to mix validations on client and server allows for the designer to pick the strategy that is optimal. In some cases this might be all server side validation, in other cases it might be all client validation, and in others the optimimum might be some mix of the two. You should allow the designer to make this choice instead of building an architecture that makes it for him. _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
