[Javascript] Where to learn JS best practices & style

[David T. Lovering]

I thought I would add a footnote on the subject of forms.

Forms were (and still are) used primarily with CGI/BIN application servers.  That is to
say, the form object in your window collects the user input, and then submits it to the
server for processing.  Whether this processing consists of initiating some kind of 
eCommerce, or merely sending some appropriate reply back, is not germane to this discussion.

However, CGI/BIN (and ASP and all things Microsoftian) have started to smell a bit in this
era of heightened security awareness.  The reason is that ALL CGI/BIN information is exchanged
as part of the URL declaration -- the stuff you see in the little window at the top of your
browser.  For example, if you hit the 'submit' button on most forms, you'll see this window
suddenly fill with lots of gobblety-gook following after your original 'naked' URL.  Most 
forms do not encrypt this data (the CPU burden on the server side would tend to be prohibitive),
so anyone with a network sniffer could suck your form data out of the ether and parse it for
such delightful bits as your credit card info, your home telephone address, etc. etc.

For complicated forms this string can grow to astonishing lengths -- and most browsers put some
sort of cap on how long they can be.  Scuttlebutt has it that IE6.X generally limits this to
2K characters, but I'm still awaiting confirmation of this.

HOWEVER (!!!) by judicious use of dereferencing child windows, using embedded SSL streams, and
server-to-client pipes, almost all of the CGI/BIN dialogue becomes unnecessary, thereby giving
our sniffer friends considerably less to look at.  I still recommend that whenever you are 
dealing with privacy-act sensitive data you use SSL (i.e; HTTPS), and use a software-generated
one-time passkey/certificate exchange to authenticate it.  

The other thing that bugs me no end is the default assumption on forms that hitting 'carriage
return' (enter) is equivalent to 'submit this form'.  Since this is counter to the user tendency
to regard enter as little more than the completion of a current field, it can cause all sorts
of problems.  The best way to deal with this is to nuke entirely the built-in form 'submit'
function (sorry Rod), and redirect it by way of a separate stand-alone function:

<script language='JavaScript'>
  <!--
    var thisForm;
    function doSubmitPreProcessing(thisForm) {
      <check all the fields for correct values>
      ...
      if (allFieldsCorrect) {
        document.thisForm.submit();
      }
    }
  // -->
</script>

<form name='myForm' id='myForm' action='javascript:void(null)'>
  ... yada-yada

  <input type='button' name='mySubmitButton' onClick='doSubmitPreProcessing(this.form)' value='Submit'>

</form>

  ,,, assumming you are actually even using the nasty old 'CGI/BIN' submit routine at all.

  About 90% of the web applications I've written in the last three years don't even use the
CGI/BIN variable-passing methodology at all, and my forms process at least 8 times faster
than the generic .asp variety -- and are 100% more secure as well.  Don't believe everything
you read in the Microsoft literature -- they've invested heavily in the easiest-to-implement
approaches, and not necessarily the most efficient or secure.

  Those few blocks that I did write using the CGI/BIN embedded-URL variable passing approach are
even now being rewritten to avoid it altogether.  It should be noted that using JavaScript,
Java, PHP, and DHTML structures can do ANYTHING you can imagine, and gives you complete autonomy
about the coding structure -- something which cannot be said of .Net, ColdFusion, and the like.

  -- Dave Lovering

"David T. Lovering" wrote:
> 
> Sorry it took so long to get back to you, but I was doing "real work" (whatever that is).
> 
> Anything which has an 'id' is part of the DOM model, and can be readily accessed.  MOST
> things which have a name can be tweaked -- the safe thing is to assign an id to everything you
> want to manipulate, and also assign a name to it which is identical.
> 
> SPANs, DIVs, and the like are no different.
> 
> One generally doesn't root around inside formatting directives (<P> for example), so this sort
> of thing is less of an issue than one might imagine.  Still, if you slap an id/name on it, you
> can generally dig about in its insides.
> 
> The rule of thumb is: anything which contains data or reflects a user selection MUST be inside
> a form to be active.  Period.  The execeptions are so rare and esoteric as to hardly be worthy
> of mention.  SPANs, DIVs and such-like are most useful when they are inside forms, but will
> work perfectly well without -- PROVIDING THEY DO NOT CONTAIN DATA OR REFLECT USER SELECTIONS!
> For example, one can place an IFRAME inside a DIV (for example) which merely includes text from
> a magazine quote -- without requiring a form.
> 
> No, you don't need the form for static objects (i.e; things the user is not expected to mess with).
> 
> Is this instance, the general methodology for DOM objects would be
> 
> document.objectName.attribute
> 
> However, having user input or 'hidden' value (<input type=hidden>) structures is so incredibly useful,
> that it is exceedingly rare NOT to need a form -- even if it never gets sent to anywhere, and just acts
> as a collection point for various tidbits which are subsequently processed by JavaScripts (or whatever)
> en situ.
> 
> Hope that answers at least a few of your questions.
> 
> -- Dave Lovering
> 
> Walter Torres wrote:
> >
> > Nice treatment on thhis subject David...
> >
> > But I do have a followup question.
> >
> >     document.formName.myobject.value
> >
> > The above is great for FORM Objects.
> >
> > What about non-FORM Objects? i.e: SPAN, P, H1, DIV, etc
> >
> > Walter
> >
> > > -----Original Message-----
> > > From: javascript-bounces at LaTech.edu
> > > [mailto:javascript-bounces at LaTech.edu]On Behalf Of David T. Lovering
> > > Sent: Saturday, March 29, 2003 1:13 AM
> > > To: [JavaScript List]
> > > Subject: Re: [Javascript] Where to learn JS best practices & style
> > >
> >
> > > > are you saying that the statement "document.all.myobject.value" is more
> > > > efficiently expressed as "myobject.value"?
> > >
> > > document.all points to everything inside the document, which is a
> > > waste of CPU and memory to cache all the
> > > ID references.  It is only used to keep the DOM nazi's happy.
> > > Real people only use it when they want to
> > > confuse newbies.
> > >
> > > Leaving off the form identifier can be bad, and one should never
> > > take the 'document' preamble in vain.  Be
> > > a good DOMite, and try
> > >
> > >   document.formName.myobject.value, making appropriate name substitutions.
> > >
> > > >
> > > > how about document.all["obj" + lnJ++].value?  is there another way to
> > > > reference a contruct like that?
> > >
> > > Let me guess -- you must have been a C++ programmer in an earlier
> > > existence.
> > >
> > > If you REALLY want to go skating down all the elements inside a form, try
> > >
> > >   for (var i=0; i<document.myForm.elements.length; i++) {
> > >     var myElement = document.myForm.elements[i];
> > >     if (myElement.value != 'undefined') {
> > >       var myValue = myElement.value;
> > >     }
> > >   }
> > >
> > > Note that there are MANY JavaScript objects which are perfectly
> > > useful, but for
> > > which '.value' is potentially meaningless.  This checks to make
> > > sure you are dealing with a
> > > nice friendly object before it tries to suck up its value.
> > >
> > > >
> > > > how different is document.all.myobject.value from
> > > > myObjArray["row6"]["col5"].value?  Maybe i'm relying too much
> > > on VB/VFP's
> > > > object model where the dotted referencing is just the nomenclature for
> > > > explicitly stating the object heirarchy.  (aside from the fact
> > > that a DHTML
> > > > document doesn't really have a heirarchy)
> > >
> > > Quite different.  One is a static object, and the other is an
> > > array which requires unpacking.
> > >
> > > As to the 'correct' books to read -- rule #1: discard everything
> > > printed by Microsoft.
> > >
> > > Rule #2: Discard anything with the words 'Idiot' or 'Dummy' in the title.
> > >
> > > Rule #3: Anything which bills itself as the 'complete' JavaScript
> > > which is less than 3 inches thick
> > > can also be discarded.
> > >
> > > All levity aside, the three references I use most often are
> > >
> > >       JavaScript Developer's Dictionary (SAMS)
> > >     PURE JavaScript (SAMS)
> > >     Professional JavaScript (2nd Edition) (Wrox)
> > >
> > > I would have recommended the JavaScript Bible, but the latest
> > > edition is nearly useless.
> > > If you can find a Third Edition, buy it, but otherwise stick to
> > > the other 3 books.  I do have about 200 others, but their utility
> > > is usually limited to one or two pet topics near and dear to the
> > > heart of their author.
> > >
> > > Also, when you see people leaving off prefixes like 'document'
> > > and 'window', rest assured that
> > > they are lazy bastards who will eventually be sent to the hot
> > > place and forced to reinsert them into
> > > the code written by other lazy bastards.
> > >
> > > >
> > > >   re: removing all the comments/short names- Are you suggesting that a
> > > > source-code be maintained with comments, and a production
> > > version without
> > > > comments?  Do you think the overhead of delivering in-line comments
> > > > outweighs the benefit of future readability/maintenance?  (consider the
> > > > target being an Intranet client with at least 10/100Mb
> > > wire-speed)  In this
> > > > same vein, do shorter (though perhaps less obvious) variable
> > > names improve
> > > > performance over more immediately readable (and somewhat
> > > "self-documenting")
> > > > variable naming conventions?  Isn't this why we've moved from 3rd to 4th
> > > > generation development languages?  By the time i've reduced my code to 3
> > > > character variable names without commenting, i might as well
> > > instantiate a
> > > > compiled object.
> > > >
> > >
> > > short names, particularly for temporary variables or indices are
> > > perfectly OK.
> > > The awkwardness is derived from describing the length of the text
> > > variable myFieldName
> > > in formA as merely being 'l'.  Five years from now you won't have
> > > a clue what 'l' is...
> > > whereas myFieldNameLength is perfectly obvious.
> > >
> > > I don't believe comments have any measurable impact on execution
> > > speed -- I believe
> > > the JavaScript in-line compiler nukes them before running the
> > > remaining code.  Anyone who
> > > wants to correct this naive delusion is welcome to step in anytime.
> > >
> > > -- Dave Lovering
> >
> > _______________________________________________
> > Javascript mailing list
> > Javascript at LaTech.edu
> > https://lists.LaTech.edu/mailman/listinfo/javascript
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript