[
https://issues.apache.org/jira/browse/MYFACES-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159697#comment-13159697
]
Leonardo Uribe commented on MYFACES-3412:
-----------------------------------------
The problem is to render the markup for an ajax request two ResponseWriters
comes into play:
org.apache.myfaces.shared.renderkit.html.HtmlResponseWriterImpl
org.apache.myfaces.context.PartialResponseWriterImpl
PartialResponseWriter wraps HtmlResponseWriterImpl. JSF 2.0 spec section
13.4.4.1 says this:
"... JavaServer Faces provides javax.faces.context.PartialResponseWriter to
ensure the Ajax response that is written follows the standard format as
specified in Section 1.3 “XML Schema Definition for Partial Responses”.
Implementations must take care to properly handle nested CDATA sections when
writing the response. PartialResponseWriter decorates an existing
ResponseWriter implementation by extending
javax.faces.context.ResponseWriterWrapper ..."
Which seems obvious, now take a look at section 13.4.4
"... The response should be in a common format so JavaScript clients can
interpret the markup in a consistent way - an important requirement for
component compatability. The agreed upon format and content type for the
partial response is XML. This means there should be a ResponseWriter suitable
for writing the response in XML ..."
With this two descriptions we can conclude that MYFACES-3339 is a bug and needs
to be fixed. Historically, there was some issues on both ResponseWriter
implementations, and the old code was a workaround. But later after solve
issues we found the right "combination".
Now take a look at section 8.1, in the part that talks about
createResponseWriter:
"... The contentTypeList parameter is an "Accept header style" list of content
types for this response, or null if the RenderKit should choose the best fit.
[P1-start-contentTypeList]The RenderKit must support a value for the
contentTypeList argument that comes straight from the Accept HTTP header, and
therefore requires parsing according to the specification of the Accept
header.[P1-end] Please see Section 14.1 of RFC 2616 (the HTTP 1.1 RFC) for the
specification of the Accept header. ..."
The same description is on the javadoc and basically it means if no
contentTypeList the RenderKit should choose the best fit but later says derive
it from Accept HTTP heade. Since the header sent by primefaces is:
Accept application/xml, text/xml, */*; q=0.01
And HtmlRenderKit has two modes xhtml and html, the best match is xml. In
theory the client side is the one responsible to send the proper header,
because in that place it is possible to know which contentType when the page
was rendered at first.
Since this behavior is specified by the spec, we can't change that part. Since
there is a valid workaround adding a RenderKit wrapper, create a config param
doesn't sound good.
It is true send <!-- --> is valid, but according to the spec text/html should
be sent into accept header so HtmlResponseWriterImpl could choose the right
match.
Looking more carefully, maybe the problem is we are using xhtml mode for
application/xml, text/xml, but it should be only used if Accept header is
application/xhtml+xml. I'll check it with more care to see if we have a problem
here.
> updated AJAX values sometimes delete other elements
> ---------------------------------------------------
>
> Key: MYFACES-3412
> URL: https://issues.apache.org/jira/browse/MYFACES-3412
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 2.0.10, 2.1.4
> Reporter: Mark Struberg
> Assignee: Werner Punz
> Attachments: ajaxbug.zip
>
>
> The attached examples shows a problem I face after updating to the latest
> 2.0.10/11 and 2.1.4/5 MyFaces versions.
> I have 2 primefaces date pickers inside a h:panelGroup. Both date pickers
> create ajax requests and refresh their values. If you click one of them (both
> update the whole panelGroup), the 2nd date picker disapears.
> This might have something to do with the AJAX js rework?
> I can easily work around this issue, but I'm not sure which other problems
> might arise as well, thus we better fix this
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
