[ 
https://issues.jboss.org/browse/RF-12536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12950635#comment-12950635
 ] 

Lukáš Fryč edited comment on RF-12536 at 3/6/14 6:22 AM:
---------------------------------------------------------

As we are now adding RichFaces specific extensions to any request, the only 
remaining differences are:

* AjaxOutputs (implicitly rendered areas) are not rendered
* meta-components can't be addressed

I think we could enable this but make it configurable - the switch would be 
pretty easy:
https://github.com/richfaces/richfaces/blob/RF-13505-refactor-epvc-3/framework/src/main/java/org/richfaces/context/ExtendedPartialViewContext.java#L756

However, since the request is not from RichFaces.ajax API, we don't have any 
clue about activator component. Note that if we override jsf.ajax.request to 
take over this logic from RichFaces.ajax, there are requests that doesn't have 
to go through this API - e.g. PrimeFaces use jQuery.ajax.

So the logic should probably be - if we don't have any knowledge of 
activatorComponent (org.richfaces.ajax.component request parameter), we should 
just skip activator visiting for collecting renderIds/executeIds and use parent 
implementation.
                
      was (Author: lfryc):
    As we are now adding RichFaces specific extensions to any request, the only 
remaining differences are:

* AjaxOutputs are not rendered
* meta-components can't be addressed

I think we could enable this but make it configurable - the switch would be 
pretty easy:
https://github.com/richfaces/richfaces/blob/RF-13505-refactor-epvc-3/framework/src/main/java/org/richfaces/context/ExtendedPartialViewContext.java#L756

However, since the request is not from RichFaces.ajax API, we don't have any 
clue about activator component. Note that if we override jsf.ajax.request to 
take over this logic from RichFaces.ajax, there are requests that doesn't have 
to go through this API - e.g. PrimeFaces use jQuery.ajax.

So the logic should probably be - if we don't have any knowledge of 
activatorComponent (org.richfaces.ajax.component request parameter), we should 
just skip activator visiting for collecting renderIds/executeIds and use parent 
implementation.
                  
> Force Extended Partial View (EPVC) processing even for partial updates 
> triggered by non-RichFaces components
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: RF-12536
>                 URL: https://issues.jboss.org/browse/RF-12536
>             Project: RichFaces
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 4.0.0.Final, 4.1.0.Final, 4.2.2.Final, 4.3.0.M1
>            Reporter: Lukáš Fryč
>              Labels: interoperability
>             Fix For: 5-Tracking
>
>
> As in case of RF-12031, when partial update (AJAX) is triggered by 
> non-RichFaces component (such as {{<f:ajax />}}), the 
> {{ExtendedPartialViewContext}} processing is skipped and default 
> {{PartialViewContext}} is processed directly.
> --This might break some concepts, e.g. partial updates of 
> {{JavaScriptService}}-rendered scripts (RF-12031).--
> This is also interoperability issue, since it will break not only for 
> {{<f:ajax />}} component, but also any third-party component triggering AJAX 
> request.

--
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

Reply via email to