[Javascript] Where to learn JS best practices & style

[dlovering at gazos.com (David T. Lovering)]

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@xxxxxxxxxx
> > [mailto:javascript-bounces@xxxxxxxxxx]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@xxxxxxxxxx
> https://lists.LaTech.edu/mailman/listinfo/javascript