Hi Stas,

Am 25.09.2004 um 21:51 schrieb Stas Bekman:

Boris Zentner wrote:
Hi,
Am 24.09.2004 um 14:30 schrieb Joe Schaefer:
Boris Zentner <[EMAIL PROTECTED]> writes:

[...]

It makes only sense the other way around. A $apr->param('parameter');
must provide a valid object.


That's why I suggested subclassing Apache::Request,
so you can have param() do whatever you want.

Thats what I'm doing already. But this is only a hack and not a solution.
- I lost all the speed from libapreq2 im really slow since I have to copy all the data to a perl object only for the lost bit.
- Since I subclass, a user can call params and get a APR::Table object that is totally unrelated to the data he is interested in.
But thats my solution unless APR::Table gets fixed.

In this email I'm not talking about libapreq which uses a sub-class of APR::Table.


To start with: APR::Table stores plain strings, it has no way to store metadata. You need to use pnotes to store perl variables (which will preserve any of the flags).

It's possible that if APR::Table sees a UTF8 flag on set(), it should encode it back to the utf8 string before storing it, since as you've pointed out there is no way to restore the UTF8 flag back. But also as you've pointed out, it's a huge waste of resources. since you will need to decoded it again, when you get() it and before you can use it.

May be expicitly setting the utf8 flag will work as a temp solution for you? If all your data is stored in utf8, then it will perfectly fine.


No, this will not work in my case.

Below is the revision of your test program, that does what you want. (If you didn't know, you can use APR:: classes outside of Apache, so you can run this program from the command line):


This aproach will not work for me, since the get part is out of my control. And I do not know which of the vars in the table are already utf8 at get time.


My current cure is to copy the table to a object, that works like APR::Table. With the wast of copy all the data even if it is not used.

Another idea to get the encoding right is:

All data in the table get the right encoding ( some data is utf some not ). Require all operations on table objects to have a cleared utf8 flag even if the data is in utf8. In that case, I can use APR::TABLE and all other ill-formed data providers. But if any datasource like databases or scalars have the utf8 flag set all data is busted again. So I have to fight against perls auto conversion ( use bytes is not helpfull since I do not controll all source ). And I fear to lose somewhere.


--
Boris


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to