As I said before, I was simply attempting to supply an answer
to the question without turning it into a philosophy debate.
However, I generally agree with your positions. Since the
original post didn't supply enough background info to make
any judgment about the appropriateness of using JS, nor do I
remember any request for discussion of suitability, it seemed
like just answering the question might be helpful. One possible
answer was that, yes, it is possible by having the browser tell
the servlet if JS is enabled. Perhaps a better method would be
simply to include a hidden tag and then set the value to a telltale
value if JS is enabled.
<form name="theForm" ...>
...
<input type="hidden" name="jsOn" value="no">
...
</form>
<script><!--
document.theForm.jsOn.value = "yes"
//--></script>
Now the form submits whether JS is enabled or not and supplies
the desired information. As to the intent of the user being a factor,
any time there is something to be gained by cheating, someone will
cheat. Without specific deployment details, such may or may not be
the case for this application. Ditto for the issue of excluding segments
of the user base. Web applications are often very narrowly targeted,
say to an admin group, where the exact capabilities of the user base
are known in advance. In these cases, writing client side application
logic may well be the best solution. However, that is clearly not the
situation here or it would not be necessary to determine if JS was
available at run time, so your premises are probably valid...T
"When you offered me a penny for my thoughts,
I never said you'd get your money's worth."
----- Original Message -----
From: "john jacobs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 20, 2001 12:31 AM
Subject: Re: JavaScript Enabled?
<snip>
> I don't think it's really an issue of intent on the part of the user, but
rather general application design. Unless one can be absolutely sure that
all of one's end users will be viewing the app via IE or Netscape, using
javascript for critical functionalities is evil, bad, and wrong.
>
> The idea of putting application logic on the client side is fine if you
know in advance the type of environment your users will be viewing your
pages in (e.g., a macintosh-specific site, or an intranet). However,I
disagree whole-heartedly with using anything flashier (no pun intended :)
than HTML 3.2 for a public application. Using client-dependant technologies
like javascript or flash effectively exclude certain segments of the user
population.
>
> In any case, using javascript should not be necessary for anything other
than presentational fluff. If the form validation is so sensitive that it
cannot withstand mistyped data or garbage, perhaps it should be revamped.
>
> just $.02,
>
> --john
>
> >
> >
> > ----- Original Message -----
> > From: "Christopher K. St. John" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, June 19, 2001 11:00 AM
> > Subject: Re: JavaScript Enabled?
> >
> >
> > > Deb Shuvabrata wrote:
> > > >
> > > > Consider a date validation on an HTML page.
> > > >
> > >
> > > You can't depend on client-side validation. Since the users
> > > have control of the client, the users can do any perverse
> > > thing they want, and there's no way to always catch them.
> > > So assume all the data coming from the client is trashed and
> > > revalidate it on the server-side.
> > >
> > > > Is there any way I can find out from my ... if the request
> > > > came from a JavaScript enabled browser or not.
> > > >
> > >
> > > No. A malicious user can always fake it, see part 1. ('But
> > > we don't have any malicious users' is not a good excuse,
> > > since stupidity is often indistinguishable from malice :-)
> > > Make sure to always validate on the server side, and you
> > > don't have to worry about javascript being turned off...
> > >
> > >
> > > --
> > > Christopher St. John [EMAIL PROTECTED]
> > > DistribuTopia http://www.distributopia.com
> > >
> > >
> >
___________________________________________________________________________
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > > of the message "signoff SERVLET-INTEREST".
> > >
> > > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > > Resources:
http://java.sun.com/products/servlet/external-resources.html
> > > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> > >
> >
> >
___________________________________________________________________________
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
