Thank you very much. I appreciate all your inputs. Nadia -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, September 30, 2004 10:41 AM To: [EMAIL PROTECTED] Subject: RE: Validate() vs JavaScript where is the advantage?
While absolutely agree with the premise that you shouldn't trust what the client sends you, I think this reponse is a little too rigid. You need to take into account the environment your working in. If your talking about a situation where your clients are captive (i.e., an internal-only application where you know the browser type coming in), you can do some things that you can't do on a public-facing site. I've built a number of apps here at work that are exceptional in the sense that many people think they are using a fat-client because of the functionality and speed they see. I could only have accomplished many of the things I have in those cases because we're an IE-only shop with virtually no chance of ever switching (I've been told this from higher-ups, so it's not my problem if they change their minds). Some of the things that makes these apps unusual is because of all the client-side scripting that is done and all the dynamic HTML tricks I play. It allows you to have a webapp that doesn't REACT like a webapp because you avoid a lot of the round-trips to the server for things that could be done on the client, and you can have functionality you couldn't do otherwise (like instantaneous sorting of a table without touching the server for instance). I'm the first to admit you have to be careful in situations like this because it's easy to cause yourself trouble if you don't do it right. And of course if they ever do decide to change browsers we're going to have problems. But this is a decision that I don't think is as clear-cut as some are saying here (unless as I said it's a public site, then yes, I think it IS clear-cut: do it all on the server!) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, September 30, 2004 10:26 am, Brantley Hobbs said: > Performance is likely to be the last thing you'll be worried about if > someone sneaks malicious input past your validation. > > Client-side form validation is just plain /wrong/! > > Never trust input you get back from a client. Never. > > Brantley > >> -----Original Message----- >> From: Nadia Kunkov [mailto:[EMAIL PROTECTED] >> Sent: Thursday, September 30, 2004 9:58 AM >> To: Struts Users Mailing List >> Subject: RE: Validate() vs JavaScript where is the advantage? >> >> Thanks for the replies. >> Have you ever noticed a performance difference though? >> Is it significant? >> Nadia >> >> >> -----Original Message----- >> From: news [mailto:[EMAIL PROTECTED] Behalf Of Jeff Beal >> Sent: Thursday, September 30, 2004 9:14 AM >> To: [EMAIL PROTECTED] >> Subject: Re: Validate() vs JavaScript where is the advantage? >> >> >> Nadia Kunkov wrote: >> > Hi, >> > I'm wondering if I should use validate() method of ActionForm > instead of >> JavaScript to validate the form. I can see the advantage of > validate() >> when you have an internationalized application, but otherwise why > would I >> have an overhead of going back to the server when I can do the > validation >> on the client side? I'm a struts newbie so I might not see the > advantage >> of validate yet, so can someone tell me why JavaScript would be an >> inferior choice ( when internationalization is not an issue ). >> > >> > Thanks >> > NK >> In short, you don't have control over your users' environment. They >> could be running old browsers; they could have JavaScript disabled; > they >> could be running a browser with non-standard JavaScript support; their >> browser could be buggy. Malicious users could even manually assemble >> HTTP requests with invalid data. >> >> By using server-side validation, you take control over all of the data >> coming into your web application. If you leave validation to the >> browser, there is always the chance that bad data is going to sneak > into >> your system and do something that you don't expect. >> >> -- Jeff >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
