Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #33811 > unrolled thread

Inserting stuff received with AJAX into the DOM

Back to article view | Back to comp.lang.javascript

Contents

  Inserting stuff received with AJAX into the DOM bit-naughty@hotmail.com - 2017-08-19 12:35 -0700
    Re: Inserting stuff received with AJAX into the DOM bit-naughty@hotmail.com - 2017-08-19 12:55 -0700
      Re: Inserting stuff received with AJAX into the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-20 12:16 +0200
        Re: Inserting stuff received with AJAX into the DOM Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2017-08-20 15:55 +0200
          Re: Inserting stuff received with AJAX into the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-20 19:18 +0200
            Re: Inserting stuff received with AJAX into the DOM Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2017-08-20 21:50 +0200
              Re: Inserting stuff received with AJAX into the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-20 22:39 +0200
                Re: Inserting stuff received with AJAX into the DOM Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2017-08-21 08:29 +0200
                  Re: Inserting stuff received with AJAX into the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-21 16:44 +0200
                    Re: Inserting stuff received with AJAX into the DOM Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2017-08-21 17:24 +0200
                      Re: Inserting stuff received with AJAX into the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-21 17:47 +0200
                        Re: Inserting stuff received with AJAX into the DOM Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2017-08-21 19:50 +0200
                          Re: Inserting stuff received with AJAX into the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-21 22:16 +0200
                            Re: Inserting stuff received with AJAX into the DOM Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2017-08-26 09:25 +0200
                              Re: Inserting stuff received with AJAX into the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-27 03:02 +0200
    Re: Inserting stuff received with AJAX into the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-20 12:30 +0200
    Re: Inserting stuff received with AJAX into the DOM bit-naughty@hotmail.com - 2017-08-20 07:37 -0700
      Re: Inserting stuff received with AJAX into the DOM "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-08-20 17:17 +0200
      Re: Inserting stuff received with AJAX into the DOM Tim Streater <timstreater@greenbee.net> - 2017-08-20 17:48 +0100
    Re: Inserting stuff received with AJAX into the DOM bit-naughty@hotmail.com - 2017-08-20 11:21 -0700
      Re: Inserting stuff received with AJAX into the DOM Tim Streater <timstreater@greenbee.net> - 2017-08-20 19:29 +0100
      Re: Inserting stuff received with AJAX into the DOM "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-08-21 01:29 +0200
        Re: Inserting stuff received with AJAX into the DOM Andrew Poulos <ap_prog@hotmail.com> - 2017-08-21 16:29 +1000
          Re: Inserting stuff received with AJAX into the DOM "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-08-21 12:25 +0200
          Re: Inserting stuff received with AJAX into the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-08-21 16:47 +0200

Page 1 of 2  [1] 2  Next page →

#33811 — Inserting stuff received with AJAX into the DOM

Assume I've run an AJAX call, and got back a response, which I put into the variable "rt":

rt = request.responseText;


I would now like to append this text to the DOM tree using appendChild, but it keeps giving this error:

"TypeError: Argument 1 of Node.appendChild is not an object."


I guess "rt" is not an object - it's just text. What is one supposed to do in this case?


Btw, I would NOT like the text to show up immediately when I do the appendChild - anything special that needs to be done??


Thanks.

[toc] | [next] | [standalone]

#33813

On Sunday, August 20, 2017 at 1:06:02 AM UTC+5:30, bit-n...@hotmail.com wrote:
> Assume I've run an AJAX call, and got back a response, which I put into the variable "rt":
> 
> rt = request.responseText;
> 
> 
> I would now like to append this text to the DOM tree using appendChild, but it keeps giving this error:
> 
> "TypeError: Argument 1 of Node.appendChild is not an object."
> 
> 
> I guess "rt" is not an object - it's just text. What is one supposed to do in this case?
> 
> 
> Btw, I would NOT like the text to show up immediately when I do the appendChild - anything special that needs to be done??
> 
> 
> Thanks.

Just to add - I would like to add "rt" into the DOM tree as a <DIV> *with a particular id* - how do I do that??

[toc] | [prev] | [next] | [standalone]

#33817

Stefan Ram wrote:

> bit-naughty@hotmail.com writes:
>>Just to add - I would like to add "rt" into the DOM tree as a
>><DIV> *with a particular id* - how do I do that??
> 
>   I'm not an expert in DOM scripting, here is an untested attempt:

s/DOM//
 
> { const text = document.createTextNode( rt );
>   const par = document.createElement( 'p' ); par.appendChild( text );
>   const div = document.createElement( 'div' ); div.appendChild( par );
>   div.setAttribute( 'id', 'particularid' );
>   whereyouwanttoappendit.appendChild( div ); }

Using the “const” keyword makes this code unnecessily incompatible.  It is 
also questionable whether “const” satisfies the semantics of the code as the 
referred values are highly mutable.

The first thing that one wants to do is to test each return values before 
one uses it:

  if (par && text) par.appendChild(text);

Even better, in a function is the “gauntlet” or “early return” approach:

  if (!(par && text)) return …;

Note that unfortunately not all DOM implementations have returned a 
reference to the appended node from .appendChild() in the past, so while 
method chaining may be appealing, it is not wise.

Then

  div.setAttribute( 'id', 'particularid' );

can and should be

  div.id = "particularid";

as it avoids one less backwards-compatible method call.

Other than that, the approach is sound: It is more efficient to construct a 
subtree in memory and append it, than to append the separate nodes to the 
document directly.  The goal here is to minimize the number of reflows.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#33819

On 20/08/2017 12:16, Thomas 'PointedEars' Lahn wrote:
> Stefan Ram wrote:
> 
>> bit-naughty@hotmail.com writes:
>>> Just to add - I would like to add "rt" into the DOM tree as a
>>> <DIV> *with a particular id* - how do I do that??
>>
>>    I'm not an expert in DOM scripting, here is an untested attempt:
> 
> s/DOM//
>   
>> { const text = document.createTextNode( rt );
>>    const par = document.createElement( 'p' ); par.appendChild( text );
>>    const div = document.createElement( 'div' ); div.appendChild( par );
>>    div.setAttribute( 'id', 'particularid' );
>>    whereyouwanttoappendit.appendChild( div ); }
> 
> Using the “const” keyword makes this code unnecessily incompatible.  It is
> also questionable whether “const” satisfies the semantics of the code as the
> referred values are highly mutable.
> 
> The first thing that one wants to do is to test each return values before
> one uses it:
> 
>    if (par && text) par.appendChild(text);
> 
> Even better, in a function is the “gauntlet” or “early return” approach:
> 
>    if (!(par && text)) return …;

My approach would be a bit different. I would rather not do that as "if" 
statement here tends to hides the potential error. Better, in my 
opinion, is to use directly:

par.appendChild(text);

"par" is always defined, but text doesn't have to be or can be passed as 
a non-string type. In that case executing par.appendChild(text); will 
throw DOM exception and the error can be spotted easily.

[...]

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#33823

Cezary Tomczyk wrote:

> On 20/08/2017 12:16, Thomas 'PointedEars' Lahn wrote:
>> Stefan Ram wrote:
>>> { const text = document.createTextNode( rt );
>>>    const par = document.createElement( 'p' ); par.appendChild( text );
>>>    const div = document.createElement( 'div' ); div.appendChild( par );
>>>    div.setAttribute( 'id', 'particularid' );
>>>    whereyouwanttoappendit.appendChild( div ); }
>> […]
>> The first thing that one wants to do is to test each return values before
>> one uses it:
>> 
>>    if (par && text) par.appendChild(text);
>> 
>> Even better, in a function is the “gauntlet” or “early return” approach:
>> 
>>    if (!(par && text)) return …;
> 
> My approach would be a bit different. I would rather not do that as "if"
> statement here tends to hides the potential error. Better, in my
> opinion, is to use directly:
> 
> par.appendChild(text);
> 
> "par" is always defined, […]

How did you get that idea?

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#33826

On 20/08/2017 19:18, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
> 
>> On 20/08/2017 12:16, Thomas 'PointedEars' Lahn wrote:
>>> Stefan Ram wrote:
>>>> { const text = document.createTextNode( rt );
>>>>     const par = document.createElement( 'p' ); par.appendChild( text );
>>>>     const div = document.createElement( 'div' ); div.appendChild( par );
>>>>     div.setAttribute( 'id', 'particularid' );
>>>>     whereyouwanttoappendit.appendChild( div ); }
>>> […]
>>> The first thing that one wants to do is to test each return values before
>>> one uses it:
>>>
>>>     if (par && text) par.appendChild(text);
>>>
>>> Even better, in a function is the “gauntlet” or “early return” approach:
>>>
>>>     if (!(par && text)) return …;
>>
>> My approach would be a bit different. I would rather not do that as "if"
>> statement here tends to hides the potential error. Better, in my
>> opinion, is to use directly:
>>
>> par.appendChild(text);
>>
>> "par" is always defined, […]
> 
> How did you get that idea?

const par = document.createElement( 'p' );

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#33827

Cezary Tomczyk wrote:

> On 20/08/2017 19:18, Thomas 'PointedEars' Lahn wrote:
>> Cezary Tomczyk wrote:
>>> "par" is always defined, […]
>> How did you get that idea?
> 
> const par = document.createElement( 'p' );

And you are sure that the method that is called on the right-hand side of 
that assignment cannot possibly return something else than a reference to
an object that has a method named “appendChild”?

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#33831

On 20/08/2017 22:39, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
> 
>> On 20/08/2017 19:18, Thomas 'PointedEars' Lahn wrote:
>>> Cezary Tomczyk wrote:
>>>> "par" is always defined, […]
>>> How did you get that idea?
>>
>> const par = document.createElement( 'p' );
> 
> And you are sure that the method that is called on the right-hand side of
> that assignment cannot possibly return something else than a reference to
> an object that has a method named “appendChild”?

I am sure that:

const par = document.createElement( 'p' );

will always create HTML element. I can't see any real scenario where 
createElement method will return "something else than a reference to an 
object that has a method named “appendChild”" in that particular scenario.

Correct me, if I am wrong.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#33846

Cezary Tomczyk wrote:

> On 20/08/2017 22:39, Thomas 'PointedEars' Lahn wrote:
>> Cezary Tomczyk wrote:
>>> On 20/08/2017 19:18, Thomas 'PointedEars' Lahn wrote:
>>>> Cezary Tomczyk wrote:
>>>>> "par" is always defined, […]
>>>> How did you get that idea?
>>> const par = document.createElement( 'p' );
>> And you are sure that the method that is called on the right-hand side of
>> that assignment cannot possibly return something else than a reference to
>> an object that has a method named “appendChild”?
> 
> I am sure that:
> 
> const par = document.createElement( 'p' );
> 
> will always create HTML element. I can't see any real scenario where
> createElement method will return "something else than a reference to an
> object that has a method named “appendChild”" in that particular scenario.

Why?
 
> Correct me, if I am wrong.

Nice try :)
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#33848

On 21/08/2017 16:44, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
> 
>> On 20/08/2017 22:39, Thomas 'PointedEars' Lahn wrote:
>>> Cezary Tomczyk wrote:
>>>> On 20/08/2017 19:18, Thomas 'PointedEars' Lahn wrote:
>>>>> Cezary Tomczyk wrote:
>>>>>> "par" is always defined, […]
>>>>> How did you get that idea?
>>>> const par = document.createElement( 'p' );
>>> And you are sure that the method that is called on the right-hand side of
>>> that assignment cannot possibly return something else than a reference to
>>> an object that has a method named “appendChild”?
>>
>> I am sure that:
>>
>> const par = document.createElement( 'p' );
>>
>> will always create HTML element. I can't see any real scenario where
>> createElement method will return "something else than a reference to an
>> object that has a method named “appendChild”" in that particular scenario.
> 
> Why?

https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement

"In an HTML document, the Document.createElement() method creates the 
HTML element specified by tagName, or an HTMLUnknownElement if tagName 
isn't recognized. In a XUL document, it creates the specified XUL 
element. In other documents, it creates an element with a null namespace 
URI."

In that particular case:

const par = document.createElement( 'p' );

this will return an HTML p element.

As for "something else than a reference to an object that has a method 
named “appendChild”" may occur, of course, but this is a very rare case 
I would say and even, if it'll occur then calling "appendChild" later 
will throw a DOM exception which I think it's good because it helps to 
catch the error on an early stage.

I just don't see a benefit of using "if" statement here instead of simple:

par.appendChild(text);

>> Correct me, if I am wrong.
> 
> Nice try :)

:-)

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#33849

Cezary Tomczyk wrote:

> On 21/08/2017 16:44, Thomas 'PointedEars' Lahn wrote:
>> Cezary Tomczyk wrote:
>>> I am sure that:
>>>
>>> const par = document.createElement( 'p' );
>>>
>>> will always create HTML element. I can't see any real scenario where
>>> createElement method will return "something else than a reference to an
>>> object that has a method named “appendChild”" in that particular
>>> scenario.
>> 
>> Why?
> 
> https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement
> […]

Certainly you can come up with something better than hearsay.
 
> In that particular case:
> 
> const par = document.createElement( 'p' );
> 
> this will return an HTML p element.

It may.
 
> As for "something else than a reference to an object that has a method
> named “appendChild”" may occur, of course, but this is a very rare case

When in doubt, be careful.

> I would say and even, if it'll occur then calling "appendChild" later
> will throw a DOM exception which I think it's good because it helps to
> catch the error on an early stage.

An exception, but not a “DOM exception” will be thrown, if the object does 
not have the method.  Or execution will simply stop with an error.  Who 
knows.  createElement() is a host object’s method.
 
> I just don't see a benefit of using "if" statement here instead of simple:
> 
> par.appendChild(text);

Defensive programming.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#33850

On 21/08/2017 17:47, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
> 
>> On 21/08/2017 16:44, Thomas 'PointedEars' Lahn wrote:
>>> Cezary Tomczyk wrote:
>>>> I am sure that:
>>>>
>>>> const par = document.createElement( 'p' );
>>>>
>>>> will always create HTML element. I can't see any real scenario where
>>>> createElement method will return "something else than a reference to an
>>>> object that has a method named “appendChild”" in that particular
>>>> scenario.
>>>
>>> Why?
>>
>> https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement
>> […]
> 
> Certainly you can come up with something better than hearsay.

Possibly there is a better explanation than just hearsay.

>> In that particular case:
>>
>> const par = document.createElement( 'p' );
>>
>> this will return an HTML p element.
> 
> It may.

Well, recently you wrote:

"As a rule of thumb, if the object in question always had the method and 
it always worked, I do not feature-test it."

Isn't now that case?

I might be wrong, but if there are cases that may strongly require "if" 
here then I'd like to know.

>> As for "something else than a reference to an object that has a method
>> named “appendChild”" may occur, of course, but this is a very rare case
> 
> When in doubt, be careful.

:-)

>> I would say and even, if it'll occur then calling "appendChild" later
>> will throw a DOM exception which I think it's good because it helps to
>> catch the error on an early stage.
> 
> An exception, but not a “DOM exception” will be thrown, if the object does
> not have the method.  Or execution will simply stop with an error.  Who
> knows.  createElement() is a host object’s method.

Right, an exception.

createElement() is a host object’s method, but it was always available 
and unless it's not modified it has been always working quite good.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#33851

Cezary Tomczyk wrote:

> On 21/08/2017 17:47, Thomas 'PointedEars' Lahn wrote:
>> Cezary Tomczyk wrote:
>>> On 21/08/2017 16:44, Thomas 'PointedEars' Lahn wrote:
>>>> Cezary Tomczyk wrote:
>>>>> I am sure that:
>>>>>
>>>>> const par = document.createElement( 'p' );
>>>>>
>>>>> will always create HTML element. I can't see any real scenario where
>>>>> createElement method will return "something else than a reference to
>>>>> an object that has a method named “appendChild”" in that particular
>>>>> scenario.
>>>>
>>>> Why?
>>>
>>> https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement
>>> […]
>> Certainly you can come up with something better than hearsay.
> 
> Possibly there is a better explanation than just hearsay.

Possibly.  Can you come up with it?
 
>>> In that particular case:
>>>
>>> const par = document.createElement( 'p' );
>>>
>>> this will return an HTML p element.
>> 
>> It may.
> 
> Well, recently you wrote:
> 
> "As a rule of thumb, if the object in question always had the method and
> it always worked, I do not feature-test it."
> 
> Isn't now that case?

This is not about not feature-testing the createElement() method.  It is 
about testing its return value before using that.
 
> I might be wrong, but if there are cases that may strongly require "if"
> here then I'd like to know.

You are trying to shift the burden of proof again.  You have claimed that 
this method can never return something unsuitable.  So how do *you* support 
that claim *other* than with hearsay from MDN (I called it “hearsay” because 
it is a wiki and there is no other reference attached to your claim)?
 
>>> I would say and even, if it'll occur then calling "appendChild" later
>>> will throw a DOM exception which I think it's good because it helps to
>>> catch the error on an early stage.
>> An exception, but not a “DOM exception” will be thrown, if the object
>> does not have the method.  Or execution will simply stop with an error. 
>> Who knows.  createElement() is a host object’s method.
> 
> Right, an exception.

So, what if no exception is being thrown by a method, would you not want to 
make sure as best as you can that the return value of a method is actually a 
reference to an object, before you attempt to access its properties?
 
> createElement() is a host object’s method, but it was always available

This is simply not true.  Maybe you are too young to know it:

Before the W3C DOM, which became a W3C Recommendation in 1998 CE (and was 
quickly adopted through Mozilla 1.0 in 2000), there have been element 
objects that did not have that method because it was introduced with the 
aforementioned API.

In what was called “Dynamic HTML” (DHTML) at the time, in Netscape Navigator 
(and later, Communicator) 4.x, there were layer objects for `LAYER` (and 
IIRC, `DIV`) elements whose content you could replace by calling their 
write() method; and in Internet Explorer and other MSHTML-based user agents 
there were element objects which had only the “innerHTML” and “outerHTML” 
properties, and several other methods (like insertAdjacentHTML() recently 
mentioned by Martin) for this instead.

> and unless it's not modified it has been always working quite good.

Based on what *data*?
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#33875

On 21/08/2017 22:16, Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
> 
>> On 21/08/2017 17:47, Thomas 'PointedEars' Lahn wrote:
>>> Cezary Tomczyk wrote:
>>>> On 21/08/2017 16:44, Thomas 'PointedEars' Lahn wrote:
>>>>> Cezary Tomczyk wrote:
>>>>>> I am sure that:
>>>>>>
>>>>>> const par = document.createElement( 'p' );
>>>>>>
>>>>>> will always create HTML element. I can't see any real scenario where
>>>>>> createElement method will return "something else than a reference to
>>>>>> an object that has a method named “appendChild”" in that particular
>>>>>> scenario.
>>>>>
>>>>> Why?
>>>>
>>>> https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement
>>>> […]
>>> Certainly you can come up with something better than hearsay.
>>
>> Possibly there is a better explanation than just hearsay.
> 
> Possibly.  Can you come up with it?

No. I was expecting you'll do that.

>>>> In that particular case:
>>>>
>>>> const par = document.createElement( 'p' );
>>>>
>>>> this will return an HTML p element.
>>>
>>> It may.
>>
>> Well, recently you wrote:
>>
>> "As a rule of thumb, if the object in question always had the method and
>> it always worked, I do not feature-test it."
>>
>> Isn't now that case?
> 
> This is not about not feature-testing the createElement() method.  It is
> about testing its return value before using that.

Got it, but still I claim that in that particular case I would not test it.

>> I might be wrong, but if there are cases that may strongly require "if"
>> here then I'd like to know.
> 
> You are trying to shift the burden of proof again.  You have claimed that
> this method can never return something unsuitable.  So how do *you* support
> that claim *other* than with hearsay from MDN (I called it “hearsay” because
> it is a wiki and there is no other reference attached to your claim)?

> You have claimed that this method can never return something unsuitable.

Let me clarify it: it may return something unexpected, but I've never 
tested return value from createElement method before I use it because 1) 
it was always working as expected and 2) I haven't got any scenario 
where I could say it's required.

>>>> I would say and even, if it'll occur then calling "appendChild" later
>>>> will throw a DOM exception which I think it's good because it helps to
>>>> catch the error on an early stage.
>>> An exception, but not a “DOM exception” will be thrown, if the object
>>> does not have the method.  Or execution will simply stop with an error.
>>> Who knows.  createElement() is a host object’s method.
>>
>> Right, an exception.
> 
> So, what if no exception is being thrown by a method, would you not want to
> make sure as best as you can that the return value of a method is actually a
> reference to an object, before you attempt to access its properties?

Generally yes, but as for the returns from createElement method I do not 
do that.

>> createElement() is a host object’s method, but it was always available
> 
> This is simply not true.  Maybe you are too young to know it:
> 
> Before the W3C DOM, which became a W3C Recommendation in 1998 CE (and was
> quickly adopted through Mozilla 1.0 in 2000), there have been element
> objects that did not have that method because it was introduced with the
> aforementioned API.
> 
> In what was called “Dynamic HTML” (DHTML) at the time, in Netscape Navigator
> (and later, Communicator) 4.x, there were layer objects for `LAYER` (and
> IIRC, `DIV`) elements whose content you could replace by calling their
> write() method; and in Internet Explorer and other MSHTML-based user agents
> there were element objects which had only the “innerHTML” and “outerHTML”
> properties, and several other methods (like insertAdjacentHTML() recently
> mentioned by Martin) for this instead.
> 
>> and unless it's not modified it has been always working quite good.
> 
> Based on what *data*?

Own experience.

I'd rather strongly urge to give me a scenarios where createElement 
method returns something different than created HTML element. I'd like 
to understand why do I need to test a return value of createElement 
method if it's actually a reference to an object, before I attempt to 
access to it's properties.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#33887

Cezary Tomczyk wrote:

> On 21/08/2017 22:16, Thomas 'PointedEars' Lahn wrote:
>> Cezary Tomczyk wrote:
>>> On 21/08/2017 17:47, Thomas 'PointedEars' Lahn wrote:
>>>> Cezary Tomczyk wrote:
>>>>> On 21/08/2017 16:44, Thomas 'PointedEars' Lahn wrote:
>>>>>> Cezary Tomczyk wrote:
>>>>>>> I am sure that:
>>>>>>>
>>>>>>> const par = document.createElement( 'p' );
>>>>>>>
>>>>>>> will always create HTML element. I can't see any real scenario where
>>>>>>> createElement method will return "something else than a reference to
>>>>>>> an object that has a method named “appendChild”" in that particular
>>>>>>> scenario.
>>>>>> Why?
>>>>> https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement
>>>>> […]
>>>> Certainly you can come up with something better than hearsay.
>>> Possibly there is a better explanation than just hearsay.
>> Possibly.  Can you come up with it?
> 
> No. I was expecting you'll do that.

That is precisely your fallacy here.  He who makes a claim carries the 
burden of proof to support it; not others carry the burden of proof to 
refute the same claim or prove the opposite claim.

>> This is not about not feature-testing the createElement() method.  It is
>> about testing its return value before using that.
> 
> Got it, but still I claim that in that particular case I would not test
> it.

It does not matter what you claim.  It matters on what kind of reasoning you 
are basing your (design) decisions.
 
>>> I might be wrong, but if there are cases that may strongly require "if"
>>> here then I'd like to know.
>> 
>> You are trying to shift the burden of proof again.  You have claimed that
>> this method can never return something unsuitable.  So how do *you*
>> support that claim *other* than with hearsay from MDN (I called it
>> “hearsay” because it is a wiki and there is no other reference attached
>> to your claim)?
>> You have claimed that this method can never return something unsuitable.
> 
> Let me clarify it: it may return something unexpected, but I've never
> tested return value from createElement method before I use it because 1)
> it was always working as expected and 2) I haven't got any scenario
> where I could say it's required.

That is precisely the problem.  Your decisions are apparently based only on 
wishful thinking.
 
>> So, what if no exception is being thrown by a method, would you not want
>> to make sure as best as you can that the return value of a method is
>> actually a reference to an object, before you attempt to access its
>> properties?
> 
> Generally yes, but as for the returns from createElement method I do not
> do that.

Not being based on sound reasoning, your decision-making process is not 
logical.
 
>>> and unless it's not modified it has been always working quite good.
>> Based on what *data*?
> 
> Own experience.

Do you realize that one’s experience is limited?
 
> I'd rather strongly urge to give me a scenarios where createElement
> method returns something different than created HTML element. I'd like
> to understand why do I need to test a return value of createElement
> method if it's actually a reference to an object, before I attempt to
> access to it's properties.

You are trying to shift the burden of proof again.  I am not playing that 
game.

Also, please trim your quotes from now on.

.
.
.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#33818

Stefan Ram wrote:

> bit-naughty@hotmail.com writes:
>>rt = request.responseText;
>>"TypeError: Argument 1 of Node.appendChild is not an object."
>>I guess "rt" is not an object - it's just text.
> 
>   You can use »document.createTextNode« to create a text entry
>   from a string.

(You are missing the point of the problem here, but ISTM that you have 
gotten it later.)

It is possible, but unlikely, that an XHR response would not contain markup.  
Therefore, one should either parse the returned markup into a document whose 
content can be imported, and appended to a parent element node of a document 
(one wants to create – with document.createDocumentFragment() – use, and 
append a document fragment in case of several nodes to be appended) –

  var doc = (new DOMParser()).parseFromString(…, "text/html");
  ….appendChild(document.importNode(doc.…, true));

– or assign it to the “innerHTML” property of that parent element node.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#33820

...OK, for some reason Google Groups is not showing Stefan Ram's posts, so I'm reading them quoted in other people's! :( Could someone quote the entire messages please?

What does " document.createElement( 'p' ); " return, exactly? An object?
And why the "const"?

[toc] | [prev] | [next] | [standalone]

#33821

bit-naughty@hotmail.com wrote on 20 Aug 2017 in comp.lang.javascript:

> ...OK, for some reason Google Groups is not showing Stefan Ram's posts,
> so I'm reading them quoted in other people's! :( Could someone quote the
> entire messages please? 

Use a real Newsgroup-reader, this NG is not a Google-group.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#33822

In article <782ded5b-7839-43c1-b59d-e7e941c5cbb7@googlegroups.com>,
<bit-naughty@hotmail.com> wrote:

>...OK, for some reason Google Groups is not showing Stefan Ram's posts, so I'm
>reading them quoted in other people's! :( Could someone quote the entire
>messages please?
>
>What does " document.createElement( 'p' ); " return, exactly? An object?
>And why the "const"?

Well you could do some research and find a site that tells you what
createElement does. In this case it creates a <p> element that you can
hook into the DOM where you want it, in this case as a child element of
a <div> element.

(doubtless PointyHead will say that's wrong and it does something else,
but the above explanation is good enough).

-- 
"The idea that Bill Gates has appeared like a knight in shining armour to
 lead all customers out of a mire of technological chaos neatly ignores 
 the fact that it was he who, by peddling second-rate technology, led them
 into it in the first place."                             - Douglas Adams

[toc] | [prev] | [next] | [standalone]

#33824

OK, I got it working to some extent, but now, after I set the id to "myid", it actually SHOWS UP on screen when I do the appendChild!!! i.e. this line:

<div id="myid">text</div>


is getting printed!!


How do I stop this??!!

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web