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

[Martin Marinschek]

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
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces