Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (hermes.apache.org: local policy)
In-Reply-To: <839A3FF5-18B1-11D9-9D34-000D9331B488@2bz.de>
References: <455F1FE1-1139-11D9-A745-000D9331B488@2bz.de>
 <87is9p16ht.fsf@gemini.sunstarsys.com>
 <6E61FA29-16EC-11D9-BC00-000A95B9602E@kineticode.com>
 <95D96DBE-171F-11D9-9D34-000D9331B488@2bz.de> <416326AF.8040502@stason.org>
 <46F5EF7F-1725-11D9-B147-000A95B9602E@kineticode.com>
 <4163346D.8000501@stason.org>
 <10D4B4DB-172C-11D9-B147-000A95B9602E@kineticode.com>
 <41633F79.6080003@stason.org> <87k6u4x7c0.fsf@gemini.sunstarsys.com>
 <4164BC19.4030802@stason.org>
 <48369F3D-187D-11D9-A063-000A95B9602E@kineticode.com>
 <41658ADE.6080407@gmx.de> <41658FE1.5050502@modperlcookbook.org>
 <D72EFAA1-189F-11D9-9D34-000D9331B488@2bz.de>
 <394BEFF9-18AB-11D9-A063-000A95B9602E@kineticode.com>
 <839A3FF5-18B1-11D9-9D34-000D9331B488@2bz.de>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <D8FD032C-18B3-11D9-A063-000A95B9602E@kineticode.com>
Content-Transfer-Encoding: 7bit
Cc: Geoffrey Young <geoff@modperlcookbook.org>,
 apreq-dev@httpd.apache.org,
 Markus Wichitill <mawic@gmx.de>
From: David Wheeler <david@kineticode.com>
Subject: Re: Apache::Request, APR::Table and UTF8
Date: Thu, 7 Oct 2004 15:54:30 -0700
To: Boris Zentner <bzm@2bz.de>

On Oct 7, 2004, at 3:37 PM, Boris Zentner wrote:

> Thats exactly how my application work. Internaly all data is in the 
> same charset for perl 5.6.1 and all is utf8 for perl >= 5.8.0.

Bricolage, too.

> The whole discussion came on since I do the conversion from 
> Apache::Request's byte strings to perls utf8 for most but not all 
> bytestrings. Then _all_ other application parts have no need to ever 
> bother with any conversion. But that is not all, other parts can also 
> insert data into the object ( utf8 or not).

Not Bricolage. It all has to be utf8 or it's not a string. It's just 
easier not to mix things up.

> Now I have a CGI like object, that is similar to pnotes inherited from 
> Apache::Request the problem here is why use Apache::Request, if I have 
> to use another tool anyway?

Well, I think it has been said that Joe will make sure that 
Apache::Request (libapreq) will do the right thing with Perl variable 
flags, incuding utf8. But in general, you shouldn't really need it. All 
I use Apache::Request for is reading parameters and headers, setting 
headers, and printing. So the only data I'm fetching from it is 
params(), really, and that can be subclassed as Paul Lindner has 
demonstrated. (And thanks for that link, Geoff--I wish I'd thought of 
that!).

   http://www.modperlcookbook.org/code/ch10/Cookbook/TransformRequest.pm

> Uhh, I do this already, but in fact I replace Apache::Request with 
> something similar, so why using Apache::Request?

I don't understand. Did you subclass it or replace it with something 
else? There's a very big difference--subclassing is much less work!

>> I think that this may not be possible given what you submit to the 
>> browser and get back from the browser is not Perl data (e.g., 
>> params). But pnotes(), for example, should do the right thing.
>
> Hmm, look:
>
> 1. the data touch my server all data is a sequence of bytes.
> 2. Apache::Request put this into a table for me. ( the data is 
> untouched utf8 or not )
> 3. my module inherited from Apache::Request convert the utf8 data to 
> utf8 with the flag inside the inherited new.
>
>   my $c = 0; # a counter to convert only some data to utf8
>   for ( values %$t ) {
>     $_ = Encode::encode_utf8($_) if ( $c++ & 1 );
>   }
>
> I need only these lines in step three and all other modules can use 
> the Apache::Request object and get straight data. Otherwise I need to 
> copy the data to maybe pnotes.

So you use your subclass where you need utf8 and use Apache::Request 
itself where you don't. No?

> a $t->get should return now the correct data regardless if the flag 
> was on or off. A $t->set store the data ( the same data as it does now 
> ) but also the flag. If a $t->get read the data back the flag is 
> restored. If the data is passed to the next handler in mod_perl it 
> works as before ( it drops/ignores the flag, the data is the same ).

I see. You're saying that because you basically store back to 
Apache::Request, you want it to remember what you've stored. But I 
don't think that Apache::Request was designed for storing data, just 
for fetching request data and sending response data.

Can you show the actual code?

Regards,

David