RE: DOM and XSLTProcessor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, April 9, 2007 3:50 am, Buesching, Logan J wrote:
> This could offer a possible workaround.
>
> Let me first state that I cannot simply do:
>
> echo htmlspecialchars_decode($proc->transformToXML($doc));
>
> If I were to do that, then it would assume that all of these encodings
> need to be decoded; which definitely is not the case.  I only want to
> do
> this for a few of the encodings, which I will know before the XSL
> processing.  I guess I can do some processing after it went through
> the
> XSL Processor to decode some of the encodings that I do not want, but
> that just seems like it would add a lot of unnecessary overhead if it
> can be avoided.

Can you special decode the limited subset on output, rather than doing
all of them on output, or hacking into the XML on input?

As I understand it...

The point is that the DATA can't have < and > in it, so if you want
that data to come through, you're going to have to encode/decode
somewhere along the line.

PHP automatically encodes for you for this very reason.

It's still up to you to interpret the data correctly at the output end.

Though I am kinda surprised the CDATA solution didn't do it...

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux