[
https://issues.jboss.org/browse/RF-12865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936370#comment-12936370
]
Brian Leathem edited comment on RF-12865 at 1/20/14 9:07 PM:
-------------------------------------------------------------
We have addresses the concerns there and make the EPVC extend
PartialViewContextWrapper and additionally we use PartialResponseWriterWrapper
for rendering our extensions, which is library-compatibility friendly approiach.
On the other way, we haven't get rid of DIRECT/WRAPPER mode yet as mentioned
here:
{quote}
--I recommend to get rid of `finallyEndDocument()` and perform the job in
`endDocument()`. I also recommend to let your partial view context impl extend
from javax.faces.context.PartialViewContextWrapper to keep RichFaces friendly
towards other JSF libraries which also offer a PVC wrapper.-- This should also
eliminate verbose/strange ContextMode.DIRECT/WRAPPED boilerplate. As to
"encoding issues" which the class' javadoc is talking about, I'm not sure what
exactly you mean there, but I believe that it has the same grounds as this
PrimeFaces problem: http://stackoverflow.com/a/9839362/157882 If this is true,
just don't do that and clearly document to the enduser that it's his
responsibility to explicitly configure the webapp and/or the server to use
UTF-8 as request parameter/body encoding, which is at most a matter of a
servlet fitler with an oneliner. This way you do not need to introduce wrapper
modes in your partial view context (at least, I did not see a clear reason why
you are doing that, other than the comment on top of the class).
{quote}
This approach makes sure that when some library renders own components, their
approach for PVC (or default JSF impl one) will be used, instead of the
approach that RichFaces takes. This is silly, but our approach (rewriting
processPartial() method) is required in order to support meta-component and
AjaxOutput rendering as discussed in RF-13317.
was (Author: lfryc):
We have addresses the concerns there and make the EPVC extend
PartialViewContextWrapper and additionally we use PartialResponseWriterWrapper
for rendering our extensions, which is library-compatibility friendly approiach.
On the other way, we haven't get rid of DIRECT/WRAPPER mode yet as mentioned
here:
{quote}
--I recommend to get rid of `finallyEndDocument()` and perform the job in
`endDocument()`. I also recommend to let your partial view context impl extend
from javax.faces.context.PartialViewContextWrapper to keep RichFaces friendly
towards other JSF libraries which also offer a PVC wrapper.-- This should also
eliminate verbose/strange ContextMode.DIRECT/WRAPPED boilerplate. As to
"encoding issues" which the class' javadoc is talking about, I'm not sure what
exactly you mean there, but I believe that it has the same grounds as this
PrimeFaces problem: http://stackoverflow.com/a/9839362/157882 If this is true,
just don't do that and clearly document to the enduser that it's his
responsibility to explicitly configure the webapp and/or the server to use
UTF-8 as request parameter/body encoding, which is at most a matter of a
servlet fitler with an oneliner. This way you do not need to introduce wrapper
modes in your partial view context (at least, I did not see a clear reason why
you are doing that, other than the comment on top of the class).
{quote}
This approach makes sure that when some library renders own components, their
approach for PVC (or default JSF impl one) will be used, instead of the
approach that RichFaces takes. This is silly, but out approach (rewriting
processPartial() method) is required in order to support meta-component and
AjaxOutput rendering as discussed in RF-13317.
> Correct deferred partial response ending by leveraging PVC wrapper chain
> ------------------------------------------------------------------------
>
> Key: RF-12865
> URL: https://issues.jboss.org/browse/RF-12865
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: third-party
> Affects Versions: 4.3.1
> Environment: weblogic 10.3.4, Myfaces 2.1.10, Richfaces 4.3.1,
> OmniFaces1.3
> Reporter: blam lam
> Assignee: Lukáš Fryč
> Labels: jsf, needs-qe
> Fix For: 5.0.0.Alpha3
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> After submit from a a4j:commandButton, it fail to re-render / update other
> component on the page.
> This problem only appear in MyFaces. It does not happens in Mojarra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
richfaces-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/richfaces-issues
