[richfaces-issues] [JBoss JIRA] (RF-12865) Correct deferred partial response ending by leveraging PVC wrapper chain

[Brian Leathem (JIRA)]

    [ 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