FAQ Topic - How do I modify the content of the current page?(2010-04-14)
in [JavaScript]
|
Prev: test code with firefox 3.5.8 or better
Next: FAQ Topic - How can I see in javascript if a web browser accepts cookies? (2010-04-16)
From: Garrett Smith on 12 May 2010 04:18 Dr J R Stockton wrote: > In comp.lang.javascript message <hs86gv$eq7$1(a)news.eternal- > september.org>, Sun, 9 May 2010 22:44:48, Garrett Smith > <dhtmlkitchen(a)gmail.com> posted: > >>>>> The above code should not be used >>>>> multiple times, but should be made a function : >>>>> >>>>> function Wryt(ID, S) { document.getElementById(ID).innerHTML = S } > >> Either you have a bunch of little functions that each call >> getElementById or you have a bunch of little functions that expect an >> element reference, or you have a decorator that does a bunch of things >> and takes either an element reference or an id. >> >> Most times you want to do so much more than set innerHTML. > > No. Most times I just want to set innerHTML. Consider, for example, my > late-draft page $lag-pts.htm. > I see some innerHTML in PopAll and DrawTall. For the purpose of the FAQ entry, the focus is on answering the question, not organizing abstractions. Wryt is a global function that takes an id and a string and tries to modify innerHTML of an element. The identifier "Wryt" is less descriptive than innerHTML. It has nothing to do with the global object, other than expecting that the element is in the same document that is loaded in that window, and it does not even check to make sure that it is before accessing its innerHTML. For your site, it is probably easy to catch the problem of missing element. However, for a page with entire sections of server-generated or included content, it is a good idea to put in a feature test so that if the element happens to be not included on the page, there is no error in that case. For example a popular website here in the US has a javascript error that is related to an element being expected in the page, when it is not there. https://post.craigslist.org/sfo/R/res/sfc/8 $(".ads textarea").val() is undefined postingForm.js (line 3) https://post.craigslist.org/js/postingForm.js jQuery finds no result, and so returns what is sometimes called "Null Object" among patterns folks. The `val` method might be to do the same and also return the empty string. Instead it returns undefined. The code then tries to access the length property off val and since val is undefined, a TypeError results. For elements that the program does not create, it is a good idea for the program to first test to determine if the element actually exists. For example: var el = document.getElementById("cassia"); if(el) { el.innerHTML = "Not real cinnamon and carcinogenic."; } -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 12 May 2010 04:33 Garrett Smith wrote: > Dr J R Stockton wrote: >> In comp.lang.javascript message <hs86gv$eq7$1(a)news.eternal- >> september.org>, Sun, 9 May 2010 22:44:48, Garrett Smith >> <dhtmlkitchen(a)gmail.com> posted: >> >>>>>> The above code should not be used >>>>>> multiple times, but should be made a function : >>>>>> >>>>>> function Wryt(ID, S) { document.getElementById(ID).innerHTML >>>>>> = S } >> >>> Either you have a bunch of little functions that each call >>> getElementById or you have a bunch of little functions that expect an >>> element reference, or you have a decorator that does a bunch of things >>> and takes either an element reference or an id. >>> >>> Most times you want to do so much more than set innerHTML. >> >> No. Most times I just want to set innerHTML. Consider, for example, my >> late-draft page $lag-pts.htm. >> > > I see some innerHTML in PopAll and DrawTall. > > For the purpose of the FAQ entry, the focus is on answering the > question, not organizing abstractions. > > Wryt is a global function that takes an id and a string and tries to > modify innerHTML of an element. The identifier "Wryt" is less > descriptive than innerHTML. It has nothing to do with the global object, > other than expecting that the element is in the same document that is > loaded in that window, and it does not even check to make sure that it > is before accessing its innerHTML. > > For your site, it is probably easy to catch the problem of missing > element. However, for a page with entire sections of server-generated or > included content, it is a good idea to put in a feature test so that if > the element happens to be not included on the page, there is no error in > that case. > > For example a popular website here in the US has a javascript error that > is related to an element being expected in the page, when it is not there. > > https://post.craigslist.org/sfo/R/res/sfc/8 > > $(".ads textarea").val() is undefined postingForm.js (line 3) > > https://post.craigslist.org/js/postingForm.js > > jQuery finds no result, and so returns what is sometimes called "Null > Object" among patterns folks. The `val` method might be to do the same > and also return the empty string. Instead it returns undefined. It should simply blow up at that point. Returning an empty string would be even more detrimental to the developer as such failures should be immediately apparent. > > The code then tries to access the length property off val and since val > is undefined, a TypeError results. That's preferable to the caller than returning a bogus result, which would cloak the mistake, making it less likely to be found and corrected. > > For elements that the program does not create, it is a good idea for the > program to first test to determine if the element actually exists. For > example: > > var el = document.getElementById("cassia"); > if(el) { > el.innerHTML = "Not real cinnamon and carcinogenic."; > } That's fine, but you don't want to do that in the guts of a GP framework. Calling My Library's OO interface, you would do something like:- var myEl = E('cassia'); if (myEl.element) { myEl.setElementHtml('Not real cinnamon and carcinogenic.'); } Without the check for the - element - method, the second call would result in an immediate failure. Some might call this "unforgiving". I call it sane. Who wants to bury mistakes? And this is another reason why chaining is a bad strategy in most cases.
From: David Mark on 12 May 2010 04:35 David Mark wrote: > Garrett Smith wrote: >> Dr J R Stockton wrote: >>> In comp.lang.javascript message <hs86gv$eq7$1(a)news.eternal- >>> september.org>, Sun, 9 May 2010 22:44:48, Garrett Smith >>> <dhtmlkitchen(a)gmail.com> posted: >>> >>>>>>> The above code should not be used >>>>>>> multiple times, but should be made a function : >>>>>>> >>>>>>> function Wryt(ID, S) { document.getElementById(ID).innerHTML >>>>>>> = S } >>>> Either you have a bunch of little functions that each call >>>> getElementById or you have a bunch of little functions that expect an >>>> element reference, or you have a decorator that does a bunch of things >>>> and takes either an element reference or an id. >>>> >>>> Most times you want to do so much more than set innerHTML. >>> No. Most times I just want to set innerHTML. Consider, for example, my >>> late-draft page $lag-pts.htm. >>> >> I see some innerHTML in PopAll and DrawTall. >> >> For the purpose of the FAQ entry, the focus is on answering the >> question, not organizing abstractions. >> >> Wryt is a global function that takes an id and a string and tries to >> modify innerHTML of an element. The identifier "Wryt" is less >> descriptive than innerHTML. It has nothing to do with the global object, >> other than expecting that the element is in the same document that is >> loaded in that window, and it does not even check to make sure that it >> is before accessing its innerHTML. >> >> For your site, it is probably easy to catch the problem of missing >> element. However, for a page with entire sections of server-generated or >> included content, it is a good idea to put in a feature test so that if >> the element happens to be not included on the page, there is no error in >> that case. >> >> For example a popular website here in the US has a javascript error that >> is related to an element being expected in the page, when it is not there. >> >> https://post.craigslist.org/sfo/R/res/sfc/8 >> >> $(".ads textarea").val() is undefined postingForm.js (line 3) >> >> https://post.craigslist.org/js/postingForm.js >> >> jQuery finds no result, and so returns what is sometimes called "Null >> Object" among patterns folks. The `val` method might be to do the same >> and also return the empty string. Instead it returns undefined. > > It should simply blow up at that point. Returning an empty string would > be even more detrimental to the developer as such failures should be > immediately apparent. > >> The code then tries to access the length property off val and since val >> is undefined, a TypeError results. > > That's preferable to the caller than returning a bogus result, which > would cloak the mistake, making it less likely to be found and corrected. > >> For elements that the program does not create, it is a good idea for the >> program to first test to determine if the element actually exists. For >> example: >> >> var el = document.getElementById("cassia"); >> if(el) { >> el.innerHTML = "Not real cinnamon and carcinogenic."; >> } > > That's fine, but you don't want to do that in the guts of a GP framework. > > Calling My Library's OO interface, you would do something like:- > > var myEl = E('cassia'); > if (myEl.element) { > myEl.setElementHtml('Not real cinnamon and carcinogenic.'); > } Oops, mixed up the API function name with the OO method. myEl.setHtml('Not real cinnamon and carcinogenic.');
From: Garrett Smith on 16 May 2010 18:05 Dr J R Stockton wrote: > In comp.lang.javascript message <hsdo99$ha$1(a)news.eternal- > september.org>, Wed, 12 May 2010 01:18:44, Garrett Smith > <dhtmlkitchen(a)gmail.com> posted: > >> Dr J R Stockton wrote: >>> In comp.lang.javascript message <hs86gv$eq7$1(a)news.eternal- >>> september.org>, Sun, 9 May 2010 22:44:48, Garrett Smith >>> <dhtmlkitchen(a)gmail.com> posted: >>> >>>>>>> The above code should not be used >>>>>>> multiple times, but should be made a function : >>>>>>> >>>>>>> function Wryt(ID, S) { document.getElementById(ID).innerHTML = S } >>>> Either you have a bunch of little functions that each call >>>> getElementById or you have a bunch of little functions that expect an >>>> element reference, or you have a decorator that does a bunch of things >>>> and takes either an element reference or an id. >>>> >>>> Most times you want to do so much more than set innerHTML. >>> No. Most times I just want to set innerHTML. Consider, for >>> example, my >>> late-draft page $lag-pts.htm. >>> >> I see some innerHTML in PopAll and DrawTall. > > The line in include1.js PopAll is reading innerHTML, not writing it : > Text = document.body ; Text = Text.textContent || Text.innerHTML > > In gravity4.htm DrawTall, a reference Tl to the target element is used > to set a reference Ts to its style, as well as being used in > Tl.innerHTML = SetSpans( ... . There is no need there for Wryt, which > would wastefully re-determine that reference. I concede that using Wryt > would require one character fewer in source code. > Case in point: Ther are contexts where what Wrty does is inappropriate. > > >> For the purpose of the FAQ entry, the focus is on answering the >> question, not organizing abstractions. > > Examples in FAQ answers should not show bad practice, OK. So it sounds like we agree that a global `Wryt` function is inappropriate. unless that is > explicitly indicated. Look into US technical sites, and you will > commonly see unnecessary code repetition. If an opportunity for a > counter-example appears, it should be taken. > The FAQ covers API design in one place: Code Guidelines. http://jibbering.com/faq/notes/code-guidelines/#design Comments on that welcome. > >> Wryt is a global function that takes an id and a string and tries to >> modify innerHTML of an element. The identifier "Wryt" is less >> descriptive than innerHTML. It has nothing to do with the global >> object, other than expecting that the element is in the same document >> that is loaded in that window, and it does not even check to make sure >> that it is before accessing its innerHTML. > > If the reference does not exist, that will generally be found on testing > the page and eliminated. Those who want to compute ID values in an > unreliable fashion can add a check, and something else to do instead. > Sounds like its time to play "broken record" again. Again, the reference might be included in some sort of include file. THe reference might need to be created by the script, but only once. In some cases, doing nothing is acceptable. In other cases, the element might need to be creative. The FAQ is not going to become a toy example for made up context. ThZe we are discussing is context-free. It shows innerHTML; not your Wrty function, not David's "My LIbrary" whatever the hell it is that sets innerHTML (poor fool cant' remember it himself), innerHTML is explained as just innerHTML. > > But remember what I said - that a set of five > document.getElementById(String).innerHTML = string > would better be done with the equivalent five Wryt calls. If you want > the element reference to be checked in Wryt, you must want it also to be > checked in the original code - which makes the saving of using an > appropriate function so much the greater. > The Wrty abstraction tells nothing of why it exists or what it does. It does not check element exists and doees not provide any fallback for when it doesn't. An identifier `setElementInnerHTML` at least makse a little sense here, but is just as pointless because it adds no value that cannot be achieved with simply using innerHTML. >> For your site, it is probably easy to catch the problem of missing >> element. However, for a page with entire sections of server-generated >> or included content, it is a good idea to put in a feature test so that >> if the element happens to be not included on the page, there is no >> error in that case. > > Only if the action taken if the reference is not found will be > satisfactory. Merely omitting an action can be a grave error. > How do you know that doing nothing when the element does not exist is acceptable? The FAQ does not need any context. > The absence of an appropriate error action is itself an error. > >> For elements that the program does not create, it is a good idea for >> the program to first test to determine if the element actually exists. >> For example: >> >> var el = document.getElementById("cassia"); >> if(el) { >> el.innerHTML = "Not real cinnamon and carcinogenic."; >> } > > > That is a fine example of hiding an error; No context is given. What the code does (nothing) is not necessarily an error. The element missing might indicate that the page is in a state where displaying that message would be inappropriate and in that case, not displaying the message would not be hiding an error. Doing that might or might not be a mistake. Such conclusions, at this point, would be hasty. the reader will be unaware > that the displayed page is not as its author hoped it would be. The > pointy-headed manager who tests the page may well miss the error. That > is indeed bad practice - common as it may be in your commercial sites. > My commercial sites? Which sites are those? Are they making any money? Because I sure could use that. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 17 May 2010 00:38
Dr J R Stockton wrote: > In comp.lang.javascript message <hsdo99$ha$1(a)news.eternal- > september.org>, Wed, 12 May 2010 01:18:44, Garrett Smith > <dhtmlkitchen(a)gmail.com> posted: > >> Dr J R Stockton wrote: >>> In comp.lang.javascript message <hs86gv$eq7$1(a)news.eternal- >>> september.org>, Sun, 9 May 2010 22:44:48, Garrett Smith >>> <dhtmlkitchen(a)gmail.com> posted: >>> >>>>>>> The above code should not be used >>>>>>> multiple times, but should be made a function : >>>>>>> >>>>>>> function Wryt(ID, S) { document.getElementById(ID).innerHTML = S } >>>> Either you have a bunch of little functions that each call >>>> getElementById or you have a bunch of little functions that expect an >>>> element reference, or you have a decorator that does a bunch of things >>>> and takes either an element reference or an id. >>>> >>>> Most times you want to do so much more than set innerHTML. >>> No. Most times I just want to set innerHTML. Consider, for >>> example, my >>> late-draft page $lag-pts.htm. >>> >> I see some innerHTML in PopAll and DrawTall. > > The line in include1.js PopAll is reading innerHTML, not writing it : > Text = document.body ; Text = Text.textContent || Text.innerHTML > > In gravity4.htm DrawTall, a reference Tl to the target element is used > to set a reference Ts to its style, as well as being used in > Tl.innerHTML = SetSpans( ... . There is no need there for Wryt, which > would wastefully re-determine that reference. I concede that using Wryt > would require one character fewer in source code. > > In the HTML source of my site, "Wryt" appears about 200 times, and > innerHTML only about 50 times. Some of those 50 are in fact used in > defining Wryt for pages not using include1.js. Some are in text. Five > are in VBscript pages. > > My "most times" is justified, and does not mean "always". > > > >> For the purpose of the FAQ entry, the focus is on answering the >> question, not organizing abstractions. > > Examples in FAQ answers should not show bad practice, unless that is > explicitly indicated. Look into US technical sites, and you will > commonly see unnecessary code repetition. If an opportunity for a > counter-example appears, it should be taken. > > >> Wryt is a global function that takes an id and a string and tries to >> modify innerHTML of an element. The identifier "Wryt" is less >> descriptive than innerHTML. It has nothing to do with the global >> object, other than expecting that the element is in the same document >> that is loaded in that window, and it does not even check to make sure >> that it is before accessing its innerHTML. > > If the reference does not exist, that will generally be found on testing > the page and eliminated. Those who want to compute ID values in an > unreliable fashion can add a check, and something else to do instead. > > > But remember what I said - that a set of five > document.getElementById(String).innerHTML = string > would better be done with the equivalent five Wryt calls. If you want > the element reference to be checked in Wryt, you must want it also to be > checked in the original code - which makes the saving of using an > appropriate function so much the greater. > >> For your site, it is probably easy to catch the problem of missing >> element. However, for a page with entire sections of server-generated >> or included content, it is a good idea to put in a feature test so that >> if the element happens to be not included on the page, there is no >> error in that case. > > Only if the action taken if the reference is not found will be > satisfactory. Merely omitting an action can be a grave error. > > The absence of an appropriate error action is itself an error. > >> For elements that the program does not create, it is a good idea for >> the program to first test to determine if the element actually exists. >> For example: >> >> var el = document.getElementById("cassia"); >> if(el) { >> el.innerHTML = "Not real cinnamon and carcinogenic."; >> } > > > That is a fine example of hiding an error; the reader will be unaware > that the displayed page is not as its author hoped it would be. The > pointy-headed manager who tests the page may well miss the error. That > is indeed bad practice - common as it may be in your commercial sites. > Absolutely. Scripts must look at the big picture. If required elements are missing for a particular feature, it must be scrapped in its entirety, not partially implemented with whatever is available. This is another reason why the chaining style is a bad idea. It leads to silent failures and/or failures with no recourse. But try to tell that to a jQuery aficionado obsessed with "conciseness". |