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

Groups > comp.lang.javascript > #23396

Re: Get inner text of HMTL element

Show all headers | View raw

Thomas 'PointedEars' Lahn wrote:
> Cezary Tomczyk wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Cezary Tomczyk wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Cezary Tomczyk wrote:
>>>> [...]
>>>>>> You probably referring to
>>>>>> http://robertnyman.com/2005/12/21/what-is-typeof-unknown/#comment-8001,
>>>>>> right?
>>>>>
>>>>> I would not refer to such nonsense.
>>>>
>>>> Just one sentence doesn't explain what is behind "nonsense".
>>>
>>> What do you mean by that?
>>
>> I mean that saying like "I would not refer to such nonsense." doesn't
>> bring any value. Instead of that I would expect: "Specified comment is
>> "nonsense" because of ... [and here are arguments]".
>
> It would be easier to say which statements in it are _not_ nonsense, as
> there are fewer of them.

Ok.

> Tom Trenka states there:
> | Internet Explorer displays “unknown” when the object in question is on the
> | other side of a COM+ bridge.
>
> Internet Explorer displays “unknown” if the result of the “typeof” operation
> is displayed in this case.  It (or rather, the JScript engine) throws an
> (AFAIK unrecoverable) exception on any other access.
>
> That “the object is on the other side of a COM+ bridge” may or may not be
> true.  Certainly it does not have to be COM+ object; a COM object suffices
> as this was the case before there was COM+.  (isMethod() came about *before*
> 2003 CE, so before COM+.)
>
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx>
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms221375(v=vs.85).aspx>
>
> | You may not know this or realize this, but MS’s XMLHTTP object is part of
> | a different COM+ object that implements IUnknown;
>
> “MS’s XMLHTTP object” is _not_ part of another object.
>
> In the form referred by the result of the expression
>
>    new ActiveXObject("Microsoft.XMLHTTP")
>
> it is a so-called “(OLE) Automation object” (an ActiveX object, now a
> special COM object) whose server name is “Microsoft” and type name is
> “XMLHTTP”.
>
> <http://msdn.microsoft.com/en-us/library/7sw4ddf8(v=vs.84).aspx>
> <http://msdn.microsoft.com/en-us/library/7sw4ddf8(v=vs.94).aspx>
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms221375(v=vs.85).aspx>
>
> | when you call methods on it, you’re doing so over a COM bridge
>
> True as of the date of the cited comment when there was no native
> XMLHttpRequest:
>
> <http://msdn.microsoft.com/en-us/library/ms535874(v=vs.85).aspx>
>
> (It should be noted that you find “XMLHttpRequest” in Microsoft's “Internet
> Explorer API Reference” but not in their “JavaScript Reference”.  One must
> conclude that it is referring to a host object, not a native JScript object
> as it is often claimed.)
>
> | and not calling native JavaScript.
>
> Nothing is called when using “typeof”.  (When you see someone naming read
> access or mere evaluation of an expression a “call”, and the thing being
> read or evaluated “called”, this is one sure sign of wannabe talk.)
>
> Internet Explorer as of the date of the cited comment supported JScript (it
> still does, it is just named differently now, mainly for marketing reasons).
>
> <http://msdn.microsoft.com/en-us/library/hbxc2t98(v=vs.84).aspx>
>
> | Basically that’s MS’s answer if you try to test or access something that’s
> | not a true part of the JScript engine.
>
> (Whether the statement that some object in *userland*¹ would be part of a
> script engine makes any sense is questionable already.  I am assuming he
> meant “part of the JScript *language*” here.)
>
> *No* DOM object, in general *no* host object, is part of JScript (the
> language, not an engine), not only COM(+) objects.  (That differentiates
> *host* objects from *native* objects.)
>
> In particular, Microsoft’s XMLHTTP object, whatever the version, is not
> provided by jscript.dll, but by mshtml.dll [“new
> ActiveXObject("Microsoft.XMLHTTP") or “new XMLHttpRequest”] or msxml2.dll
> [new ActiveXObject("Msxml2.XMLHTTP")].
>
> | Before you complain about it further, bear in mind that MSXML was designed
> | to be used from any MS platform,
>
> True.  However, MSXML does not have to be used.
>
> | including VB and C++;
>
> Microsoft Visual Basic and (Microsoft Visual) C++ are programming languages,
> not (computing) platforms.  (x86 is a platform.)
>
> <http://en.wikipedia.org/wiki/Computing_platform>
>
> | there are methods and properties on XMLHTTP that are useless in scripting
> | and even cause some confusion (such as the much maligned onreadystate,
>
> There is no “onreadystate”; there is an “onreadystatechange” property on XHR
> objects.
>
> <http://msdn.microsoft.com/en-us/library/ms760305(v=vs.85).aspx>
> <http://msdn.microsoft.com/en-us/library/ie/dd576252(v=vs.85).aspx>
>
> | which makes plenty of sense once you realize that MSXMLHTTP, when used
> | from C++ and VB, give you full interactive access to the internal IStream
> | via the responseStream property.)
>
> This statement does not make any sense.  He claims that “there are methods
> and properties that are useless in *scripting* …” and that this makes sense
> because “MSXMLHTTP, when used from C++ and VB [*not* from scripting], gives
> you full interactive access …“?
>
> It is necessary to make sure that the value of the “readyState” property has
> reached the value of 4 (“DONE”) before one accesses the “responseText” or
> “responseXML” properties.  It is not clear what Tom Trenka meant here, but
> if he means “readyState” (instead of “onreadystate” which does not exist),
> he is simply talking nonsense.
>
> There is/was a “responseStream” property in the IXMLHttpRequest interface,
> but whether it is/was available to userland I do not know.  (The latest Wine
> upgrade broke my capability of running IE 6.)  I assume it was not available
> because of the return type; the returned (referred) value would have to
> implement IStream.
>
> <http://msdn.microsoft.com/en-us/library/ms760305(v=vs.85).aspx>	
> <http://msdn.microsoft.com/en-us/library/ie/hh772830(v=vs.85).aspx>

Thank you very much for above explanation.

> At least Robert Nyman subsequently pointed out – in a way – that Tom
> Trenka’s logic must be flawed.  (You need to read more carefully.)

I was reading whole article few weeks before I've posted the link. 
Probably I have overlook something, but will try to read more carefully 
next time.

>>>>>>> […]  Anyhow, there is no guarantee that if some arbitrary
>>>>>>> element object has a “firstChild” or “nextSibling” property, the
>>>>>>> *target* element object also has it.
>>>>>>>
>>>>>>> Do you see now why it is a bad idea to infer from one property to
>>>>>>> another, even if the property names are the same and only the objects
>>>>>>> differ?
>>>>>> Then what options do I have?
>>>>>>
>>>>>> 1. Check, if firstChild and nextSibling is available on
>>>>>> document.documentElement or 2. Check, if every element support
>>>>>> firstChild and nextSibling?
>>>>> 3. Check if the *target* element supports “firstChild” and
>>>>> “nextSibling”.
>>>> Ok
>>>>
>>>>> 4. Forget the whole idea.
>>> Except point no. 3.
>>> What do you mean by that?
>>
>> "Forget the whole idea." - I thought that point no. 3 is the right thing
>> to do and "whole idea" is not applicable for that point.
>
> I understood your 1. and 2. to be alternatives, mutually exclusive; so 3.
> and 4. are alternatives I suggested, equally mutually exclusive and
> excluding 1. and 2.

1. I will more closely again at JSX how it's done there.
2. Solution no. 3 - I am fine with that.

>>>>>>>>> I avoid strict comparison against property values of host objects.
>>>>>>>>> There are too many unknowns.
>>>>>>>> I've never had problems with that, but I am not claim that there is
>>>>>>>> no problems. However, if you have a time then provide maybe some
>>>>>>>> valuable source where I can read about above problems. Otherwise,
>>>>>>>> skip it, in case of having no time.
>>>>>>> You are still operating in “Show me where it fails” mode in place of
>>>>>>> logic.
>>>>>> But "There are too many unknowns." doesn't teach me why.
>>>>> There is no indication that an interface’s *attribute* MUST be
>>>>> implemented as a host object’s property using a *native* type or the
>>>>> *specified* type. However, if it is to be useful, it must be
>>>>> implemented so that it allows conversion to and from a native type.
>>>> Hm, I am lost at that point.
>>> What did you not understand?
>>
>> I had a bit of homework and explore the knowledge. So, here what I
>> understood now: "interface’s *attribute*" represent
>> https://developer.mozilla.org/en-US/docs/Web/API/Attr.
>
> No, that has nothing to do with it.  Instead:
>
> The W3C/WHATWG DOM specifies interfaces (APIs) with attributes and methods:
>
> <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/introduction.html>
>
> Those interfaces are implemented in a programming language (usually, C or
> C++).  The implementations are exposed (via language binding) by host
> environments (like Web browsers) to (here) ECMAScript-based programming
> languages as (here) properties and methods of objects:
>
> <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/ecma-script-binding.html>
>
> We only know that the type of an attribute of an interface must be
> convertible to a native ECMAScript type.  Otherwise the implementation of
> the interface would be useless to userland code.
>
> We do not know, for example, if the implementor heeded the specification and
> implemented the “tabIndex” attribute of the HTMLInputElement interface as a
> property that stores a number value; it makes as much sense to use a string
> value (even more sense, considering IEEE-754 precision and *really* large
> documents).  This has happened with style properties in the past and it may
> happen again.  (If that reads like paranoia, consider the current
> non-concept of a “Living Standard”.)
>
> <http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>

Again, thank you for above explanation.

>> However, looks like "nodeType" property, at least in Gecko implementation,
>> is deprecated (I see it in section "Deprecated properties and methods").
>
> You need to read more carefully:

Even, if I am reading carefully it doesn't means that's everything is 
clear for me for the first time. Documentation may not be clear, for 
example. ;-)

> ,----
> | Warning: In DOM Core 1, 2 and 3, Attr inherited from Node. This is no
> | longer the case in DOM4. In order to bring the implementation of Attr up
> | to specification, work is underway to change it to no longer inherit from
> | Node. You should not be using any Node properties or methods on Attr
> | objects. Starting in Gecko 7.0 (Firefox 7.0 / Thunderbird 7.0 / SeaMonkey
> | 2.4), the ones that are going to be removed output warning messages to the
> | console. You should revise your code accordingly. See Deprecated
> | properties and methods for a complete list.
> `----
>
>> So, I should use
>> https://developer.mozilla.org/en-US/docs/Web/API/Element.getAttributeNode
>> to check if property exists and then decide to use its value?
>
> No.
>
>> Or do something else?
>
> Yes.
>
>>>>> You can and should skip the first *bogus* test, and do *only* the
>>>>> *reliable* test on the target object.  This comes at a price, though:
>>>>> if you cannot recognize the object (for example, through mapping), you
>>>>> will be forced to do the same test for each object when it is accessed.
>>>>> AISB: Slower, but not as error-prone as your/DM’s “one-size-fits-all”
>>>>> initialization or whatever you/he call(s) it instead.
>>>>
>>>> How reliable test on the target object may look in my case? Asking to
>>>> understand more deeply.
>>>
>>> In your case, AFAICS the target object is an arbitrary element object
>>> and, because of recursion, each of its descendant node objects.  So you
>>> will have to test each of those objects at least once.  (Of course, if
>>> “textContent” is supported on the element object of your initial
>>> serialization call, you can return its value and are done.  No iteration
>>> and recursion necessary then.)
>>
>> Is then sufficient to check property only once on the root element of
>> the document?
>
> In general, no.
>
>> Just what you wrote in previous message(s).
>>
>> if (typeof document.documentElement != "undefined"
>>         && typeof document.documentElement.textContent == "string")
>>     {[...]
>
> Just to refine your error-prone code.

Ok, will refine my code based on how it's done in JSX. At least I'll try.

>> Of course, then I need to assume that other elements support textContent
>> as well as Element
>              ^the?

Yes, the.

>> (https://developer.mozilla.org/en-US/docs/DOM/element) that is the root
>> element of the document.
>
> Yes, depending on whether you omitted the definite article above and I
> understand you correctly.

Thank you helping me and sorry for some delay in response.

> ______
> ¹ For lack of a better term.  With “userland” I do not mean only “outside
>    the kernel” of the operating system, as it is commonly understood, but
>    also outside the language implementation as provided by the runtime
>    environment.  Or, if you consider the features provided by the script
>    engine (the language implementation) your kernel – the core of the
>    language –, the part that the user of the script engine cannot change,
>    outside of *that* kernel.

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

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 18:21 +0100
  Re: Get inner text of HMTL element Martin Honnen <mahotrash@yahoo.de> - 2014-02-22 19:31 +0100
    Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 20:51 +0100
      Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 21:11 +0100
        Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 21:37 +0100
          Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 22:05 +0100
            Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 23:38 +0100
              Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-23 10:43 +0100
                Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-23 14:50 +0100
                Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-23 15:48 +0100
                Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-24 21:01 +0100
                Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 22:34 +0100
                Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-27 21:41 +0100
                Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-27 22:32 +0100
                Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-28 13:44 +0100
                Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-28 16:54 +0100
                Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-03-04 20:51 +0100
                Re: Get inner text of HMTL element ompalompasales2@gmail.com - 2014-03-04 12:59 -0800
  Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 20:59 +0100
    Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-22 22:23 +0100
      Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-22 23:32 +0100
  Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-22 21:27 -0300
    Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-23 05:35 +0100
      Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-23 15:29 -0300
        Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-23 21:01 +0100
    Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-23 20:02 +0100
      Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-23 21:55 +0100
        Re: Get inner text of HMTL element Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-02-24 08:37 +0100
          Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 12:30 +0100
            Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-24 15:09 -0300
              Re: Get inner text of HMTL element Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-24 19:43 +0100
                Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-24 18:12 -0300
                Re: Get inner text of HMTL element Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-24 22:51 +0100
              Re: Get inner text of HMTL element Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-25 19:49 +0000
                Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-26 05:20 -0300
                Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-26 17:10 +0100
                OT - Re: Get inner text of HMTL element Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-02-26 15:48 -0300
                Re: OT - Re: Get inner text of HMTL element "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-26 22:43 +0100
                Re: OT - Re: Get inner text of HMTL element Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-27 15:00 +0000
                Re: OT - Re: Get inner text of HMTL element "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-02-28 10:50 +0100
                Re: OT - Re: Get inner text of HMTL element "se" <se@no-one.here> - 2014-02-27 10:57 +0100
                Re: Get inner text of HMTL element Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-02-27 15:46 +0000

csiph-web