Loading ...
Sorry, an error occurred while loading the content.
 

Re: [frontierkernel] setting attributes on elements in compiled xml

Expand Messages
  • Andre Radke
    ... Oops. You re right, of course. ... Hm, neither seems very appealing to me, but I don t have an alternative solution either. -Andre
    Message 1 of 8 , Jun 8, 2005
      At 15:25 Uhr -0400 08.06.2005, Seth Dillingham wrote:
      > >Can you work around this bug by having xml.setAttribute convert the
      >>entities when it creates a /pcdata entry from an existing
      >>attribute-less element?
      >
      >That only makes sense if you're always going to run the results through
      >xml.decompile().

      Oops. You're right, of course.

      >I only see two possible fixes for this: a new, optional flag for
      >xml.decompile() which tells it to be consistent, or something
      >completely new like xml.decompile2().
      >
      >Or we can just leave the bug in there and let everybody work around it.

      Hm, neither seems very appealing to me, but I don't have an
      alternative solution either.

      -Andre
    • Seth Dillingham
      ... I found a way to keep it consistent. I ve changed xml.setAttribute to create the /pcdata entry with a serialized name prefix, like 0001000 t/pcdata . So,
      Message 2 of 8 , Jun 8, 2005
        On 6/8/05, Andre Radke said:

        >>That only makes sense if you're always going to run the results
        >>through xml.decompile().
        >
        >Oops. You're right, of course.

        I found a way to keep it consistent.

        I've changed xml.setAttribute to create the /pcdata entry with a
        serialized name prefix, like "0001000\t/pcdata". So, the new line in
        xml.setAttribute is:

        xml.addValue( adrElement, "/pcdata", tempValue )

        When run through xml.decompile, the /pcdata entry is still inserted
        into the output string as it should be. The difference is that the
        'special characters '<' and '&' are converted to xml entities.

        So, the inconsistency is that "/pcdata" items are not "entified"
        (characters converted to xml entities), but serialized
        "0001000\t/pcdata" items ARE entified.

        This stuff's always an adventure, isn't it?

        Frankly, I'd like it if xml.decompile didn't entify the output at all
        (or at least had an *option* to not entify at all) but I can live with
        it now that I see how to keep it consistent.

        Seth
      Your message has been successfully submitted and would be delivered to recipients shortly.