Re: [frontierkernel] setting attributes on elements in compiled xml
- At 15:25 Uhr -0400 08.06.2005, Seth Dillingham wrote:
> >Can you work around this bug by having xml.setAttribute convert theOops. You're right, of course.
>>entities when it creates a /pcdata entry from an existing
>That only makes sense if you're always going to run the results through
>I only see two possible fixes for this: a new, optional flag forHm, neither seems very appealing to me, but I don't have an
>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.
alternative solution either.
- On 6/8/05, Andre Radke said:
>>That only makes sense if you're always going to run the resultsI found a way to keep it consistent.
>Oops. You're right, of course.
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.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.