[
https://issues.jboss.org/browse/RF-12865?page=com.atlassian.jira.plugin.s...
]
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