[jsr-314-open] Adding handling of CDATA blocks in ResponseWriter

[Alexandr Smirnov]

Great! JSF is gradually going to get full XML support. I've offered
sometimes to switch into standard SAX handler instead of proprietary
writer, because Java has a wide range of tools for XML processing. It
would be better to move ResponseWriter into SAX ContentHandler and
complimentary interfaces, or at least define all necessary methods to
use simple wrapper for XML based libraries.
The processing instructions, DTD and namespaces have to have special
processing too. If ResponseWriter  is going to changes, it makes sense
to implement additional methods:
1) namespace-avare versions of startElement/endElement/writeAttribute
methods.
2) startDTD/endDTD methods.
3) 'writeComment' or 'comment' method.
4) 'startEntity'/'endEntity' methods.
5) processingInstruction


Jim Driscoll wrote:
> That's added in the codebase (as of yesterday), and as you mention,
> those methods had to be added in ResponseWriterWrapper as well.
>
> Jim
>
> On 4/7/09 5:49 AM, Martin Marinschek wrote:
>> 2) Add two new menthods, startCDATA() and endCDATA() to ResponseWriter.
>>
>> yes, please!
>>
>> regards,
>>
>> Martin
>>
>> P.S.: do we already have a ResponseWriterWrapper?
>>
>> regards,
>>
>> Martin
>>
>> On 4/4/09, Kito Mann<kito.mann at virtua.com>  wrote:
>>> On Apr 3, 2009, at 2:53 PM, Pete Muir<pmuir at REDHAT.COM>  wrote:
>>>
>>>> On 2 Apr 2009, at 20:50, Jim Driscoll wrote:
>>>>
>>>>> Greetings EG memebers.
>>>>>
>>>>> I have an implementation problem, and the cleanest, most effective
>>>>> solution is a change in the API, so I'm sending you this email.
>>>>>
>>>>> The problem:
>>>>>
>>>>> The current javax.faces.context.ResponseWriter class is aware of
>>>>> XML structure, in that it has methods for writing things like
>>>>> Elements, Comments, and Attributes.  However, CDATA blocks are
>>>>> currently not handled by the API defined there.
>>>>>
>>>>> The RI previous to this release got around this problem by
>>>>> overloading the startElement and endElement method semantics - if
>>>>> you passed a tag name of "CDATA", then it would start a CDATA block.
>>>>>
>>>>> Since nothing in the public API used CDATA, this worked fine.
>>>>>
>>>>> Now, for PartialRequests, CDATA blocks are used by the API.
>>>>>
>>>>> You cannot embed CDATA blocks within CDATA blocks, so both the API
>>>>> and the Impl need to be aware of when CDATA blocks happen, and they
>>>>> need to coordinate their actions.
>>>>>
>>>>> This means that we need to update ResponseWriter to be aware of
>>>>> CDATA blocks.
>>>>>
>>>>> There are two ways we can go about doing this:
>>>>>
>>>>> 1) Standardize the existing behavior of the implementation, so that
>>>>> startElement("CDATA", component) and endElement("CDATA") start and
>>>>> end CDATA blocks.
>>>>>
>>>>> or
>>>>>
>>>>> 2) Add two new menthods, startCDATA() and endCDATA() to
>>>>> ResponseWriter.
>>>> I strongly prefer this approach, it doesn't rely on magic.
>>> +1
>>>>
>>>>>
>>>>> I marginally favor the first approach, mostly since it's not a
>>>>> common need, it's less work, and it doesn't add two new methods
>>>>> that almost noone will use.  It's also the way that the RI
>>>>> currently uses, which hasn't seemed to cause any issues.  (It also
>>>>> requires less RI work, so that may be biasing me, though that's
>>>>> almost never a reason to chose a public API.)
>>>>>
>>>>> Ryan somewhat favors the second approach, since it's cleaner,
>>>>> architecturally, to separate out the start and stop of the cdata.
>>>>>
>>>>> But in the end, we're open to which ever way the consensus of the
>>>>> EG goes.
>>>>>
>>>>> Please reply by COB Monday on this issue, if you have an opinion.
>>>>> We need to wrap this up quickly, we're under a great deal of time
>>>>> pressure.
>>>>>
>>>>> Jim
>>>> -- 
>>>> Pete Muir
>>>> http://www.seamframework.org
>>>> http://in.relation.to/Bloggers/Pete
>>>
>>
>>