Return-Path: 
 <cocoon-dev-return-38535-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 31611 invoked by uid 500); 17 Mar 2003 00:16:30 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 31598 invoked from network); 17 Mar 2003 00:16:30 -0000
Received: from pop015pub.verizon.net (HELO pop015.verizon.net)
 (206.46.170.172)
  by daedalus.apache.org with SMTP; 17 Mar 2003 00:16:30 -0000
Received: from verizon.net ([141.156.47.107]) by pop015.verizon.net
          (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP
          id <20030317001637.PLDN14460.pop015.verizon.net@verizon.net>
          for <cocoon-dev@xml.apache.org>; Sun, 16 Mar 2003 18:16:37 -0600
Message-ID: <3E7513E4.607@verizon.net>
Date: Sun, 16 Mar 2003 19:16:36 -0500
From: Vadim Gritsenko <vadim.gritsenko@verizon.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [proposal] fixing the encoding problems
References: <BA9ABA5F.1670E%pier@betaversion.org>
In-Reply-To: <BA9ABA5F.1670E%pier@betaversion.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Authentication-Info: Submitted using SMTP AUTH at pop015.verizon.net from
 [141.156.47.107] at Sun, 16 Mar 2003 18:16:36 -0600
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Pier Fumagalli wrote:

<snip/>

>So, in my opinion, the "best" way to tackle the charset-encoding problem is
>to have the org.apache.cocoon.serialization.AbstractTextSerializer to
>receive an OutputStream from its implementation of the
>SitemapOutputComponent interface, but to expose to its solid implementations
>another couple of methods, instead of "getOutputStream":
>
>- String getCharsetEncoding() [or getCharacterEncoding]:
>    
>    Returns the default character encoding configured for the specified
>    AbstractTextSerializer (or the default one for the sitemap if none
>    was specified).
>    This can be usefult (for example) in the HtmlSerializer so that a new
>    <meta http-equiv="Content-Type" content="text/html; charset=???"/>
>    tag can be added automagically to the output, or to the "XMLSerializer"
>    so that the "<?xml version="1.0" encoding="???"?>" initial processing
>    instruction can be constructed appropriately.
>

It (<?xml?> instruction) done via 
format.put(OutputKeys.ENCODING,encoding.getValue()) in abstract 
serializer itself.


>- Writer getWriter():
>
>    Returns a java.io.Writer encoding character data to the response output
>    stream according to whatever is returned by getCharsetEncoding
>
>Those two should be controlled from the sitemap by (as you, Stefano, said):
>  
>

Sounds good.


>>2) also, i want a way to overwrite the sitemap-wide behavior of every
>>single serializers, locally, such as
>>
>> <map:serialize encoding="UTF-8"/>
>>    
>>
>
>The only "nitpick" I have is that since "encoding" means a lot of things,
>this should be called "charset" (which is way more specific)...
>
>This can be easily picked up by the AbstractTextSerializer.configure()
>method and returned by the two methods added above...
>
>I can work on a patch if you guys want... It's pretty trivial indeed...
>

Not that trivial. Configure works only globally. Right now serializers 
do not have local configuration - because they don't implement 
SitemapModelComponent and its setup() method.

Sitemap implementation has to be changed to test serializers for 
SitemapModelComponent interface, and caching pipeline should test for it 
too (IIRC, old implementation did that, not sure about new one).

Vadim


>    Pier
>