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 <bzm@xxxxxx> 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
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
| 
