On Tue, 26 Feb 2002, Daisuke Maki wrote: > > > > > Anyway, I do generally think it's a bad idea, but I'm not the definitive > > word on this by any stretch. Plus if you patch XSP.pm you'll need to patch > > XSP::CharsetConv accordingly, so that it converts stuff to the document's > > character set. Which of course means that when you use CharsetConv, you'll > > be doing two translations - once to the docs charset, then again to UTF-8 > > for libxml to be able to understand. I hope you can see how this slows > > down everyone's XSP pages ;-) > > Yes, I definitely undesrtand the performance issue. I was expecting ti > get this :) > > But otherwise, because we already have to assume that external variables > be in UTF-8 compatible encoding ( and you have to convert every expr to > your own encoding ) *anyways*, I'm not 100% convinced that this is > *such* a bad idea... But I'm willing to trust everybody's judgement on this.
No, you have to convert every variable to UTF-8 right now. Under your patch, you'd have to convert everything to the XSP page's encoding (a lossy conversion, assuming the XSP page isn't in Unicode already). > Anyway, I just would like to stress that as a multi-byte-character-user > the fact that I have to enclose every <xsp:expr>values with > <char:charset-convert> to make my database query results show up in xsp > is a *royal* pain, and if I weren't so immersed into the world of Perl > and XML, I'd probably look for another XML Content Delivery framework -- > which is a shame, because in all other aspects I really think AxKit just > rocks. How are you doing your queries? I'm sure we could find a better way. ESQL has in built support for alternate encodings in the database, for example (or at least it should, assuming I wrote that part already...). -- <!-- Matt --> <:->Get a smart net</:-> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
