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

Groups > comp.lang.javascript > #23265

Re: Get inner text of HMTL element

Show all headers | View raw

Cezary Tomczyk wrote:

> Thomas 'PointedEars' Lahn wrote:
>>    /**
>>     * Determines if a value refers to an object.
>>     *
>>     * <p>Returns <code>true</code> if the value is a reference
>>     * to an object; <code>false</code> otherwise.</p>
>>     *
>>     * <p>An value "is an object" if it is a function or
>>     * <code>typeof "object"</code> but not <code>null</code>.
>>     *
>>     * @return {boolean}
>>     */
>>    function _isObject (a)
>>    {
>>      var t = typeof a;
>>      return t == "function" || t == "object" && a !== null;
> 
> How about using toString() to get the type of object?
> 
> Object.prototype.toString.call(a).match(/\s([a-zA-Z]+)/)[1].toLowerCase()

There is jsx.object.getClass() which does something similar (more efficient, 
less error-prone), but it is not a good idea to use it here: the [[Class]] 
property of an ECMAScript value does not tell whether the value is a 
primitive value or a reference to an object, and with host objects all bets 
are off, even if one would be willing and able to invest the resources to 
keep the list up-to-date.
 
>> A refined method would support specification of the property path as an
>> Array of string values, and primitive false-values.  I am working on it.
> 
> That would be nice.

The former is implemented now, but it needs to be (unit-)tested before it 
can be merged to the live branch.  Check the trunk on my WebSVN (or read 
<news:26292757.AuDnbMLnkA@PointedEars.de> p.)

>>>>>        get_inner_text = function(node) {
>>>>>            return node.textContent;
>>>>>        };
>>>>> } else if (document.createTreeWalker) {
>>>>
>>>> Insufficient and error-prone feature test for a host object's method,
>>>> see jsx.object.isHostMethod().
>>>
>>> Yes, I know isHostMethod, but still I am feeling that it's not enough.
>>> Checking if host object is a function is one thing, but the second one
>>> if it's native or not. Once I had a scenario where trim() method was
>>> exists, but it was overwritten by some 3rd party library and this method
>>> wasn't working well. I've just realized it after some investigation :-(
>>>
>>> However, last time I was thinking if it's strongly required every time
>>> for every scenario. As I remember:
>>>
>>> 1. Some host objects in IE8 are as an "object", not a "function".
>>> 2. There is type "unknown", but it's related to only one case.
>>>
>>> That's why I've been thinking that explicit conversion in that case is
>>> relatively safe.
>>
>> Your logic is flawed.  It had been unrecoverable exceptions being thrown
>> upon type-converting tests of host object's methods in MSHTML that
>> prompted my/the creation of isMethod(), later isHostMethod(), in the
>> first place.
> 
> You probably referring to
> http://robertnyman.com/2005/12/21/what-is-typeof-unknown/#comment-8001,
> right?

I would not refer to such nonsense.
 
>> last branch.  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”.

4. Forget the whole idea.
 
>>>>>        get_inner_text = function(node) {
>>>>>            var txt = '';
>>>>>
>>>>>            node = node.firstChild;
>>>>>            while (node) {
>>>>>                if (node.nodeType === 3 || node.nodeType === 4) {
>>>>
>>>> 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.
 
>>>>>                node = node.nextSibling;
>>>>>            }
>>>>>            return txt;
>>>>>        };
>>>>> }
>>>>>
>>>>> How about that?
>>>>
>>>> I do not think it is a good idea to infer from the existence of a
>>>> property on one (host) object the existence of a property of the same
>>>> name on another
>>>
>>> Hm, is it then better to do in that way?
>>>
>>> var get_inner_text = (function () {
>>>
>>>       // here check what is available and return function
>>>
>>> }());
>>
>> No, same problem: The feature test does not happen on the target object
>> because that object is not reliably accessible yet (if it even exists).
> 
> So, the object itself must checked as well. It is in your above code,
> right?

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.
 
>>>> That aside, you should reconsider the actual probability that
>>>> Node::textContent (DOM Level 3) would not be implemented but
>>>> Document::createTreeWalker() (DOM Level 2 Traversal and Range) was.
>>> Hm, maybe it is worth it to remove textContent and focus only on
>>> createTreeWalker or normal recursive iteration? Less code to
>>> maintenance.
>> And much less efficient with regard to runtime and memory.  You should as
>> yourself instead whether there is any actual *need* for tree-walking at
>> this point.
> 
> Well, looking at
> https://developer.mozilla.org/en-US/docs/Web/API/Node.textContent looks
> like textContent is supported by major browsers. If I will drop IE8
> support then I can focus only on textContent, I think.

Never believe blindly in anything you read; be sceptical and *verify* it.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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