Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 4 of 4
  1. #1
    Regular Coder
    Join Date
    Aug 2010
    Location
    Southern Oregon
    Posts
    305
    Thanks
    63
    Thanked 1 Time in 1 Post

    object literal with function defined fails.

    I have the following object literal defined:
    Code:
    /*
    defined in containing object instance
    */
    var params =
          {
           'act':'',
           'itemType':'',
           'current':'',        // path from home to current dir listed.
           'src':'',            // file or dir name
           'dest':'',           // file or dir name
           'field':'',          // destination path || set perms spec.
           'srcDirPth':'',      // path to src from home dir
           'destDirPth':'',     // path to dest from home dir
           'copy':'false',      // option for rename and move
           'listOnLoad':'same', // list dir on completion. set to path value on ajax.sub
           'setProp':function(a, b){ this[a] = b}
         }
    And this is were setProp is called: (in response to async query to server for directory listing)
    This is a web interface content management application I am working on

    You will notice that the alert dialogs return typeof(params.setProp) function and string
    So Why would the data type be string when nothing else is done to it?

    Code:
    /*
    code inside contain object instance
    */
    var current = document.getElementById('current');
     if(current)
       {
         if(current.hasChildNodes())
           {
             if(path)
               {
                 current.childNodes[0].data = homeDir+'/'+path;
                 alert(typeof(params.setProp)) // -> function <<<<
                 params.setProp('current', homeDir+'/'+path);
                }
              else
                {
                  current.childNodes[0].data = homeDir;
                  alert(typeof(params.setProp)) // -> string <<<<
                  params.setProp('current', homeDir); // TypeError: params.setProp is not a function
                }
           }
        else
          {
            current.appendChild(textNode(homeDir+'/'+path))
            params.setProp('current', homeDir+'/'+path);
           }
      }
    The params variable is shared between two object instances using new (constructor function).
    One object instance is created inside another object instance and programmed to accept
    references to properties and methods from the object it is contained in.

    The basic idea:
    Code:
    function one(a)
      {
        var first = a;
        return first;
      }
    
    function two()
      {
        var first = function()
             {
              alert('Hello?....')
             }
       var b = new one(first)
       return b
     }
    var second = new two()
    second() // "Hello?..."
    In my experience, this LOOKS like a bug.

    Any thoughts?

    Thanks for time and attention
    JK

  2. #2
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,126
    Thanks
    4
    Thanked 455 Times in 444 Posts
    childNodes is a problematic way of looking into elements simply because comments and textNodes are nodetypes as well. The problem could in fact be in your markup. You want the firstElementChild (aka childNode[0]) use firstElementChild... though beware legacy IE has no such reference but it can be polyfilled by checking firstChild's nodeType, then if it's not nodeType 1 iterate through nextSibling until that's null, or nodetype is 1.

    It's also a bit of a wonk you are assigning "data" to an unknown node type. I'm not even certain that makes sense unless you're defining that yourself. Neither textNodes nor Element have a 'data' property last I knew. Are you trying to replace that element's contents? Is that index[0] supposed to be a textNode or an Element?

    Might also help if you weren't repeating yourself so much...

    I'd have to see the markup to make much sense of this. JavaScript that walks the DOM is hard to follow when you don't know what's at the end of the chain wearing the collar.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  3. #3
    Regular Coder
    Join Date
    Aug 2010
    Location
    Southern Oregon
    Posts
    305
    Thanks
    63
    Thanked 1 Time in 1 Post

    childNodes[x]

    When I use this reference: childNodes[0], I am targeting a span or pre tag with a specific id.
    The tag is created just for the sake of displaying an error or status string. So it has either no
    child nodes or one text node which is set or removed by other code. I almost never us p tags.
    Pre tags can be set with a className property that has a set of style rules. So the default
    fixed width font is not used.

    I also use span and pre tags as host elements for containing predetermined content. These
    predetermined elements can be remove or replaced with different versions depending on user
    activity. So I don't need to hunt around for a place to put something or find a particular node type.
    To remove I can just loop through childNodes and remove each in turn. It doesn't have to be done
    recursively either, in my experience. Remove a childNode that has childNodes, will also remove
    its childNodes.

    JK

  4. #4
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,126
    Thanks
    4
    Thanked 455 Times in 444 Posts
    Still not sure ANY of that makes a lick of sense, and again suspect that if we could see the markup or structure you're manipulating it would be more clear what you're trying to accomplish.

    This REALLY seems more like a job for firstChild or firstElementChild than the slower buggy childNodes / hasChildNodes.

    It seems like you're just randomly making up attributes -- is this a non-HTML compliant XML structure or something? (again, there's no such thing as a "data" attribute in HTML)

    If this is indeed working on a HTML page, try to avoid going around and just making stuff up... or if you do follow the data_ or dataList methods for doing so!

    I'm just not seeing any bug, I'm seeing bad/broken/nonsensical methodology top to bottom.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com


 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •