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

[Jim Driscoll]

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