Re: POST Method



Michael Winter wrote:
If you must refer to a form, do it properly:

  document.forms.myForm.submit();

However, the more important concern is of no client-side scripting support. Navigation should never depend upon a script.

And, if you're going to make absolute statements, you should do *that* properly. Pedanticism is a 2 way street.


Navigation should never depend on a script where scripting engine availability and compatibility can't be assured or the exclusion of clients to whom the scripting functionality will be unavailable causes undue harm.

Personally, I avoid absolute statements whenever I can, because I know that my grasp of all possible scenarios is meager at best. And, absolute statements, particularly those stating "rules" that aren't actually scientific rules or laws tend to be based on a very specific set of assumed criteria, which often don't match the questioner's situation. This results in people following the "rules" to the detriment of their project because they don't understand the reasoning behind the rules.

For instance, your rule against scripting is based on these assumptions:

1. Publicly accessible site with a "normal" distribution of browsers including the most recent versions of Mozilla and IE as well as older versions and more obscure browsers.
2. That a certain number of the viewers will have scripting either completely incompatible or disabled.
3. That it is a "site" in the first place.


Not all of these things is true for every project. Seriously. I've built PHP/Javascript applications that aren't accessed through a regular browser at all. Rather, a customized wrapper around IE is used to launch the app in fullscreen kiosk mode and is required to send the MAC address of the ethernet adapter to be allowed into the app. In this case, there was 100% IE and 100% Javascript compatibility/enabled. I could also assume 1024x768 as all of the client setups were identical and imaged from the same disk image. If I'd wasted time avoiding IE-specific scripting or worked at all on cross-browser setup, I'd have been wasting my client's money. The project would have suffered for blindly following the rules.

So, what's the closest thing I use to a rule in regard to these kinds of solutions? Figure out your userbase and make sure that *they* can use it, whoever "they" are and quit clinging to absolute rules.

Remember, when someone asks how to do something, they may have a very different purpose (an entirely reasonable purpose) in mind for the technology. Just because you can't imagine a scenario that's appropriate, don't assume one doesn't exist. Use the right tools for the job.
.




Relevant Pages

  • Re: how to Enable/Disable textbox dynamically
    ... If you need a client-side solution, don't post server-side code ... and must not occur as child of the `html' element. ... it escapes me why you are relying on client-side scripting this ...
    (comp.lang.javascript)
  • Re: CheckBox CheckChanged EventHandler not working?
    ... was hoping I wouldn't need to have any client side scripting. ... much that an event handler would be able to change stuff on a webform w/o the ... > about client-side script instead if you expect high traffic. ... >> I have a login page with two checkboxes, one for automatic login and the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Form Validation - Is this possible?
    ... Using client-side scripting to disable the submit button, ... So the validation needs to be done on the server side, ... whether this would be more efficient than a simple form submission. ...
    (comp.lang.javascript)
  • Re: strange html table behavior
    ... Also it is a *very bad* idea to rely on *client-side* scripting to load your page, about 10% have JavaScript disable and they too will get a beautiful black white page! ... Since you are on a IIS server you should use server-side ASP or SSI. ...
    (alt.html)
  • Re: click submit button and refresh the form data in existing window??
    ... Now, you've opened the new window and given it a name, and submitted your ... You might post future questions to a client-side scripting group, ... In page2.jsp, the user can see the exact form data filed out in page1.asp,> and user can modify the form data in page2.jsp, and click> a button, it will update the existing form data in page1.asp. ...
    (microsoft.public.inetserver.asp.general)