RE: getElementByID() - Patch

[Jeff Lewis <jd...@xactware.com>]

Here is a patch for that:
 
void CharacterDataImpl::setNodeValue(const DOMString &value)
{
    if (readOnly())
        throw
DOM_DOMException(DOM_DOMException::NO_MODIFICATION_ALLOWED_ERR,
                               null);
 
 NodeImpl* parent = getParentNode();
 if (parent)
 {
  if (parent->isAttrImpl() && parent->idAttr())
  {
   parent->setNodeValue(value);
   return;
  }
 }
    data = value.clone();
};


-----Original Message-----
From: Jeff Lewis [mailto:jdlewis@xactware.com]
Sent: Tuesday, May 16, 2000 11:31 AM
To: 'xerces-c-dev@xml.apache.org'
Subject: RE: getElementByID() - Patch <BUG_2>


The reason that this is happening is that the node that contains the value
for the attribute is actually of type CharacterDataValue.  So when you do a
setNodeValue, the CharacterDataValue::setNodeValue() function gets called.
 
I guess that this function needs to find-out the following:
1) Is this the first child of the parent    (I'm not sure if this in
necessary.)
2) Is the parent an attribute
3) Is the parent an ID attribute
 
If those three items are true, then the parent's AttrImpl::setNodeValue
should be called either instead, or after the
CharacterDataValue::setNodeValue() gets called.
 
 

-----Original Message-----
From: Andy Heninger [mailto:andyh@jtcsv.com]
Sent: Tuesday, May 16, 2000 10:51 AM
To: xerces-c-dev@xml.apache.org
Subject: Re: getElementByID() - Patch <BUG_2>


It looks like there's yet another bug lurking in this general area.
 
If an application changes the attribute value by modifying the text node(s)
rather than by setting the value on the attribute node, the change will not
propagate back into the hash table.
 
And, unrelated to getElementById, I betcha that the attributes "specified"
flag does not get set if this happens.  Something to be checked, anyhow.
 
 
Andy Heninger
IBM XML Technology Group, Cupertino, CA
heninger@us.ibm.com <ma...@us.ibm.com> 

Re: getElementByID() - Patch

[Andy Heninger <an...@jtcsv.com>]

RE: getElementByID() - Patch <BUG_2>Hi Jeff,

There are even more complications involved with changing an attribute value by fiddling with the child Text nodes.  DOM_CharacterData has a number of editing methods, all of which must trigger the change.  Also, the children of an attribute node can include entity references intermixed with any number of text nodes, so we can't just slam a single Text in as the new value.  The children of entity references themselves are read only, so at least we don't need to worry about them changing.  Also, there is a problem with the specified property of a DOM_Attribute not being maintained correctly when this type of change occurs, and this is closely enough related that it probably should be fixed at the same time.

All in all, I'm half inclined to leave this whole mess as an open bug for now.


Andy Heninger
IBM XML Technology Group, Cupertino, CA
heninger@us.ibm.com
  ----- Original Message ----- 
  From: Jeff Lewis 
  To: 'xerces-c-dev@xml.apache.org' 
  Sent: Tuesday, May 16, 2000 10:38 AM
  Subject: RE: getElementByID() - Patch <BUG_2b> 


  Here is a patch for that:

  void CharacterDataImpl::setNodeValue(const DOMString &value)
  {
      if (readOnly())
          throw DOM_DOMException(DOM_DOMException::NO_MODIFICATION_ALLOWED_ERR,
                                 null);

   NodeImpl* parent = getParentNode();
   if (parent)
   {
    if (parent->isAttrImpl() && parent->idAttr())
    {
     parent->setNodeValue(value);
     return;
    }
   }
      data = value.clone();
  };

    -----Original Message-----
    From: Jeff Lewis [mailto:jdlewis@xactware.com]
    Sent: Tuesday, May 16, 2000 11:31 AM
    To: 'xerces-c-dev@xml.apache.org'
    Subject: RE: getElementByID() - Patch <BUG_2>


    The reason that this is happening is that the node that contains the value for the attribute is actually of type CharacterDataValue.  So when you do a setNodeValue, the CharacterDataValue::setNodeValue() function gets called.

    I guess that this function needs to find-out the following:
    1) Is this the first child of the parent    (I'm not sure if this in necessary.)
    2) Is the parent an attribute
    3) Is the parent an ID attribute

    If those three items are true, then the parent's AttrImpl::setNodeValue should be called either instead, or after the CharacterDataValue::setNodeValue() gets called.


      -----Original Message-----
      From: Andy Heninger [mailto:andyh@jtcsv.com]
      Sent: Tuesday, May 16, 2000 10:51 AM
      To: xerces-c-dev@xml.apache.org
      Subject: Re: getElementByID() - Patch <BUG_2>


      It looks like there's yet another bug lurking in this general area.

      If an application changes the attribute value by modifying the text node(s) rather than by setting the value on the attribute node, the change will not propagate back into the hash table.

      And, unrelated to getElementById, I betcha that the attributes "specified" flag does not get set if this happens.  Something to be checked, anyhow.


      Andy Heninger
      IBM XML Technology Group, Cupertino, CA
      heninger@us.ibm.com