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

Kito Mann kito.mann at VIRTUA.COM
Fri Apr 3 22:18:09 EDT 2009


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




More information about the jsr-314-open-mirror mailing list