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

On Apr 3, 2009, at 2:53 PM, Pete Muir <pmuir(a)REDHAT.COM&gt; 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

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&lt;kito.mann(a)virtua.com&gt; wrote: >> On Apr 3, 2009, at 2:53 PM, Pete Muir&lt;pmuir(a)REDHAT.COM&gt; 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 >> > >

On 4/7/09 2:10 PM, Alexandr Smirnov wrote: > 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. Something easily pluggable would probably be nice for 2.1 (though I'd imagine that the ResponseWriterWrapper could be used for that task now, if you had a mind to do it). The CDATA code was added simply because there was no other way to coordinate between the impl and the api that didn't involve convoluted code, but it's easy to imagine a need for more full support - in which case, being able to plug something in cleanly would serve that need best (though for many applications, the simple interface of ResponseWriter will probably continue to be sufficient, so I would argue against deprecating it).

Jim