[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-12897:
---------------------------------
I have added the fix into RF-13505 feature branch - it will be resolved once RF-13505 is merged into master.
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Labels: richfaces
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
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
10 years, 2 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-12897:
---------------------------------
The big part is addressed by RF-13505, the only remaining logic where RichFaces could swallow exceptions is {{MetaComponentEncodingVisitCallback}}.
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Labels: richfaces
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
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
10 years, 2 months
[JBoss JIRA] (RF-12536) Force Extended Partial View (EPVC) processing even for partial updates triggered by non-RichFaces components
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12536?page=com.atlassian.jira.plugin.s... ]
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 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/fram...
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:
* AjaxOutpus 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/fram...
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
10 years, 2 months
[JBoss JIRA] (RF-12536) Force Extended Partial View (EPVC) processing even for partial updates triggered by non-RichFaces components
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12536?page=com.atlassian.jira.plugin.s... ]
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/fram...
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/fram...
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
10 years, 2 months
[JBoss JIRA] (RF-12536) Force Extended Partial View (EPVC) processing even for partial updates triggered by non-RichFaces components
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12536?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-12536:
----------------------------
Comment: was deleted
(was: A comment with security level 'JBoss Employee' was removed.)
> 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
10 years, 2 months
[JBoss JIRA] (RF-12536) Force Extended Partial View (EPVC) processing even for partial updates triggered by non-RichFaces components
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12536?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-12536:
----------------------------
Description:
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.
was:
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.
> 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
10 years, 2 months
[JBoss JIRA] (RF-12536) Force Extended Partial View (EPVC) processing even for partial updates triggered by non-RichFaces components
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12536?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-12536:
---------------------------------
As we are now adding RichFaces specific extensions to any request, the only remaining differences are:
* AjaxOutpus 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/fram...
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
10 years, 2 months
[JBoss JIRA] (RF-12536) Force Extended Partial View (EPVC) processing even for partial updates triggered by non-RichFaces components
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12536?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-12536:
----------------------------
Summary: Force Extended Partial View (EPVC) processing even for partial updates triggered by non-RichFaces components (was: Force ExtendedPartialViewContext processing even for partial updates triggered by non-RichFaces components)
> 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
10 years, 2 months
[JBoss JIRA] (RF-13567) JavaScriptService executes javascript before the complete event
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13567?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-13567 at 3/6/14 4:52 AM:
---------------------------------------------------------
Brian, I don't think this is incorrect behavior unless I miss something.
* onbeforedomupdate is called
* DOM is updated by JSF
** note: this step may execute <script>s included in the response (not completely sure when it is evaluated)
* javascriptService is called on before complete event
* oncomplete is called
So the elements should be placed in the DOM already when DOM is updated. ^
Idea: Is it possible that JSF DOM update causes to add a <script> with jQuery plugin execution and it is this script execution that adds elements you expect to be present already?
----
Note: the oncomplete event serves as notification for the user to know that every synchronous update of the page caused by partial response was processed. There should be no RichFaces specific logic following the execution of oncomplete event.
was (Author: lfryc):
Brian, I don't think this is incorrect behavior unless I miss something.
* onbeforedomupdate is called
* DOM is updated by JSF
** note: this step may execute <script>s included in the response (not completely sure when it is evaluated)
* javascriptService is called on before complete event
* oncomplete is called
So the elements should be placed in the DOM already when DOM is updated. ^
Is it not possible that JSF DOM update causes to add a <script> with jQuery plugin execution and it is this script execution that adds elements you expect to be present already?
----
Note: the oncomplete event serves as notification for the user to know that every synchronous update of the page caused by partial response was processed. There should be no RichFaces specific logic following the execution of oncomplete event.
> JavaScriptService executes javascript before the complete event
> ---------------------------------------------------------------
>
> Key: RF-13567
> URL: https://issues.jboss.org/browse/RF-13567
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Brian Leathem
>
> Using the javascript service to execute jQuery plugins ends up with the plugin being executed before the new elements are placed in the DOM. This results in stale element references during subsequent plugin execution.
> Console log with r:log enabled:
> {code}
> RichFaces: New request added to queue. Queue requestGroupingId changed to form1:richTable:0:collapsibleSubTable log.js:195
> RichFaces: Queue will wait 0ms before submit log.js:195
> RichFaces: richfaces.queue: will submit request NOW log.js:195
> RichFaces: Received 'begin' event from <tbody id=form1:richTable:0:collapsibleSubTable class=rf-cst ...> log.js:195
> Destroy called for sub-table-bridge of element: form1:richTable:0:collapsibleSubTable sub-table-bridge.js:89
> Destroy called for sub-table of element: form1:richTable:0:collapsibleSubTable sub-table.js:71
> RichFaces: Received 'beforedomupdate' event from <tbody id=form1:richTable:0:collapsibleSubTable class=rf-cst ...> log.js:195
> RichFaces: <span>Server returned responseText: </span><span class="rf-log-entry-msg-xml"><partial-response id="j_id1"><changes><update id="form1:richTable:0:collapsibleSubTable"><![CDATA[<tbody id="form1:richTable:0:collapsibleSubTable" class="rf-cst"><tr id="form1:richTable:0:collapsibleSubTable:f" class="rf-cst-ftr"><td class="rf-cst-ftr-c" colspan="3">footer<ul class="data-scroller " id="form1:richTable:0:collapsibleSubTable:subscroller"><li><a class="rf-ds-btn rf-ds-btn-first rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_f">««««</a></li><li><a class="rf-ds-btn rf-ds-btn-fastrwd rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_fr">««</a></li><li><a class="rf-ds-btn rf-ds-btn-prev rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_prev">«</a></li><li><a class="rf-ds-btn rf-ds-btn-next rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_next">»</a></li><li><a class="rf-ds-btn rf-ds-btn-fastfwd rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_ff">»»</a></li><li><a class="rf-ds-btn rf-ds-btn-last rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_l">»»»»</a></li><script type="text/javascript">new RichFaces.ui.DataScroller("form1:richTable:0:collapsibleSubTable:subscroller",function(event,element,data){RichFaces.ajax("form1:richTable:0:collapsibleSubTable:subscroller",event,{"parameters":{"form1:richTable:0:collapsibleSubTable:subscroller:page":data.page} ,"incId":"1"} )},{"digitals":{} ,"buttons":{} ,"currentPage":1} )</script></ul></td></tr><tr id="form1:richTable:0:collapsibleSubTable:sc" style="display: none;"><td><input id="form1:richTable:0:collapsibleSubTable:state" name="form1:richTable:0:collapsibleSubTable:state" type="hidden" value="0" /><input id="form1:richTable:0:collapsibleSubTable:options" name="form1:richTable:0:collapsibleSubTable:options" type="hidden" /></td></tr></tbody>]]></update><update id="j_id1:javax.faces.ViewState:0"><![CDATA[-7868019542578483246:-4058924891838140372]]></update><extension id="org.richfaces.extension"><complete>RichFaces.jQuery(document.getElementById('form1:richTable:0:collapsibleSubTable')).subTableBridge({"optionsInput":"form1:richTable:0:collapsibleSubTable:options","formId":"form1","expandMode":"ajax","stateInput":"form1:richTable:0:collapsibleSubTable:state","eventOptions":{"incId":"1"} } );RichFaces.javascriptServiceComplete();;</complete><render>form1:richTable:0:collapsibleSubTable@body </render></extension></changes></partial-response></span> log.js:195
> RichFaces: <span>Listing content of response <b>changes</b> element:<br>Element <b>update</b> for id=form1:richTable:0:collapsibleSubTable<br><span class="rf-log-entry-msg-xml"><update id="form1:richTable:0:collapsibleSubTable"><![CDATA[<tbody id="form1:richTable:0:collapsibleSubTable" class="rf-cst"><tr id="form1:richTable:0:collapsibleSubTable:f" class="rf-cst-ftr"><td class="rf-cst-ftr-c" colspan="3">footer<ul class="data-scroller " id="form1:richTable:0:collapsibleSubTable:subscroller"><li><a class="rf-ds-btn rf-ds-btn-first rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_f">««««</a></li><li><a class="rf-ds-btn rf-ds-btn-fastrwd rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_fr">««</a></li><li><a class="rf-ds-btn rf-ds-btn-prev rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_prev">«</a></li><li><a class="rf-ds-btn rf-ds-btn-next rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_next">»</a></li><li><a class="rf-ds-btn rf-ds-btn-fastfwd rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_ff">»»</a></li><li><a class="rf-ds-btn rf-ds-btn-last rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_l">»»»»</a></li><script type="text/javascript">new RichFaces.ui.DataScroller("form1:richTable:0:collapsibleSubTable:subscroller",function(event,element,data){RichFaces.ajax("form1:richTable:0:collapsibleSubTable:subscroller",event,{"parameters":{"form1:richTable:0:collapsibleSubTable:subscroller:page":data.page} ,"incId":"1"} )},{"digitals":{} ,"buttons":{} ,"currentPage":1} )</script></ul></td></tr><tr id="form1:richTable:0:collapsibleSubTable:sc" style="display: none;"><td><input id="form1:richTable:0:collapsibleSubTable:state" name="form1:richTable:0:collapsibleSubTable:state" type="hidden" value="0" /><input id="form1:richTable:0:collapsibleSubTable:options" name="form1:richTable:0:collapsibleSubTable:options" type="hidden" /></td></tr></tbody>]]></update></span><br>Element <b>update</b> for id=j_id1:javax.faces.ViewState:0<br><span class="rf-log-entry-msg-xml"><update id="j_id1:javax.faces.ViewState:0"><![CDATA[-7868019542578483246:-4058924891838140372]]></update></span><br>Element <b>extension</b> for id=org.richfaces.extension<br><span class="rf-log-entry-msg-xml"><extension id="org.richfaces.extension"><complete>RichFaces.jQuery(document.getElementById('form1:richTable:0:collapsibleSubTable')).subTableBridge({"optionsInput":"form1:richTable:0:collapsibleSubTable:options","formId":"form1","expandMode":"ajax","stateInput":"form1:richTable:0:collapsibleSubTable:state","eventOptions":{"incId":"1"} } );RichFaces.javascriptServiceComplete();;</complete><render>form1:richTable:0:collapsibleSubTable@body </render></extension></span><br></span> log.js:195
> Create called for sub-table-bridge of element: form1:richTable:0:collapsibleSubTable sub-table-bridge.js:42
> Create called for sub-table of element: form1:richTable:0:collapsibleSubTable sub-table.js:22
> RichFaces: richfaces.queue: ajax submit successfull log.js:195
> RichFaces: richfaces.queue: Nothing to submit log.js:195
> RichFaces: Received 'success' event from <tbody id=form1:richTable:0:collapsibleSubTable class=rf-cst ...> log.js:195
> RichFaces: Received 'complete' event from <tbody id=form1:richTable:0:collapsibleSubTable class=rf-cst ...> log.js:195
> {code}
> Note the "create" debug statements called from the plugin _create methods occur before we get to the complete event.
--
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
10 years, 2 months
[JBoss JIRA] (RF-13567) JavaScriptService executes javascript before the complete event
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13567?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-13567 at 3/6/14 4:52 AM:
---------------------------------------------------------
Brian, I don't think this is incorrect behavior unless I miss something.
* onbeforedomupdate is called
* DOM is updated by JSF
** note: this step may execute <script>s included in the response (not completely sure when it is evaluated)
* javascriptService is called on before complete event
* oncomplete is called
So the elements should be placed in the DOM already when DOM is updated. ^
Is it not possible that JSF DOM update causes to add a <script> with jQuery plugin execution and it is this script execution that adds elements you expect to be present already?
----
Note: the oncomplete event serves as notification for the user to know that every synchronous update of the page caused by partial response was processed. There should be no RichFaces specific logic following the execution of oncomplete event.
was (Author: lfryc):
Brian, I don't think this is incorrect behavior unless I miss something.
* onbeforedomupdate is called
* DOM is updated by JSF
* javascriptService is called on before complete event
* oncomplete is called
So the elements should be placed in the DOM already when DOM is updated. ^
Is it not possible that JSF DOM update causes to add a <script> with jQuery plugin execution and it is this script execution that adds elements you expect to be present already?
----
Note: the oncomplete event serves as notification for the user to know that every synchronous update of the page caused by partial response was processed. There should be no RichFaces specific logic following the execution of oncomplete event.
> JavaScriptService executes javascript before the complete event
> ---------------------------------------------------------------
>
> Key: RF-13567
> URL: https://issues.jboss.org/browse/RF-13567
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Brian Leathem
>
> Using the javascript service to execute jQuery plugins ends up with the plugin being executed before the new elements are placed in the DOM. This results in stale element references during subsequent plugin execution.
> Console log with r:log enabled:
> {code}
> RichFaces: New request added to queue. Queue requestGroupingId changed to form1:richTable:0:collapsibleSubTable log.js:195
> RichFaces: Queue will wait 0ms before submit log.js:195
> RichFaces: richfaces.queue: will submit request NOW log.js:195
> RichFaces: Received 'begin' event from <tbody id=form1:richTable:0:collapsibleSubTable class=rf-cst ...> log.js:195
> Destroy called for sub-table-bridge of element: form1:richTable:0:collapsibleSubTable sub-table-bridge.js:89
> Destroy called for sub-table of element: form1:richTable:0:collapsibleSubTable sub-table.js:71
> RichFaces: Received 'beforedomupdate' event from <tbody id=form1:richTable:0:collapsibleSubTable class=rf-cst ...> log.js:195
> RichFaces: <span>Server returned responseText: </span><span class="rf-log-entry-msg-xml"><partial-response id="j_id1"><changes><update id="form1:richTable:0:collapsibleSubTable"><![CDATA[<tbody id="form1:richTable:0:collapsibleSubTable" class="rf-cst"><tr id="form1:richTable:0:collapsibleSubTable:f" class="rf-cst-ftr"><td class="rf-cst-ftr-c" colspan="3">footer<ul class="data-scroller " id="form1:richTable:0:collapsibleSubTable:subscroller"><li><a class="rf-ds-btn rf-ds-btn-first rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_f">««««</a></li><li><a class="rf-ds-btn rf-ds-btn-fastrwd rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_fr">««</a></li><li><a class="rf-ds-btn rf-ds-btn-prev rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_prev">«</a></li><li><a class="rf-ds-btn rf-ds-btn-next rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_next">»</a></li><li><a class="rf-ds-btn rf-ds-btn-fastfwd rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_ff">»»</a></li><li><a class="rf-ds-btn rf-ds-btn-last rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_l">»»»»</a></li><script type="text/javascript">new RichFaces.ui.DataScroller("form1:richTable:0:collapsibleSubTable:subscroller",function(event,element,data){RichFaces.ajax("form1:richTable:0:collapsibleSubTable:subscroller",event,{"parameters":{"form1:richTable:0:collapsibleSubTable:subscroller:page":data.page} ,"incId":"1"} )},{"digitals":{} ,"buttons":{} ,"currentPage":1} )</script></ul></td></tr><tr id="form1:richTable:0:collapsibleSubTable:sc" style="display: none;"><td><input id="form1:richTable:0:collapsibleSubTable:state" name="form1:richTable:0:collapsibleSubTable:state" type="hidden" value="0" /><input id="form1:richTable:0:collapsibleSubTable:options" name="form1:richTable:0:collapsibleSubTable:options" type="hidden" /></td></tr></tbody>]]></update><update id="j_id1:javax.faces.ViewState:0"><![CDATA[-7868019542578483246:-4058924891838140372]]></update><extension id="org.richfaces.extension"><complete>RichFaces.jQuery(document.getElementById('form1:richTable:0:collapsibleSubTable')).subTableBridge({"optionsInput":"form1:richTable:0:collapsibleSubTable:options","formId":"form1","expandMode":"ajax","stateInput":"form1:richTable:0:collapsibleSubTable:state","eventOptions":{"incId":"1"} } );RichFaces.javascriptServiceComplete();;</complete><render>form1:richTable:0:collapsibleSubTable@body </render></extension></changes></partial-response></span> log.js:195
> RichFaces: <span>Listing content of response <b>changes</b> element:<br>Element <b>update</b> for id=form1:richTable:0:collapsibleSubTable<br><span class="rf-log-entry-msg-xml"><update id="form1:richTable:0:collapsibleSubTable"><![CDATA[<tbody id="form1:richTable:0:collapsibleSubTable" class="rf-cst"><tr id="form1:richTable:0:collapsibleSubTable:f" class="rf-cst-ftr"><td class="rf-cst-ftr-c" colspan="3">footer<ul class="data-scroller " id="form1:richTable:0:collapsibleSubTable:subscroller"><li><a class="rf-ds-btn rf-ds-btn-first rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_f">««««</a></li><li><a class="rf-ds-btn rf-ds-btn-fastrwd rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_fr">««</a></li><li><a class="rf-ds-btn rf-ds-btn-prev rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_prev">«</a></li><li><a class="rf-ds-btn rf-ds-btn-next rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_next">»</a></li><li><a class="rf-ds-btn rf-ds-btn-fastfwd rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_ff">»»</a></li><li><a class="rf-ds-btn rf-ds-btn-last rf-ds-dis" id="form1:richTable:0:collapsibleSubTable:subscroller_ds_l">»»»»</a></li><script type="text/javascript">new RichFaces.ui.DataScroller("form1:richTable:0:collapsibleSubTable:subscroller",function(event,element,data){RichFaces.ajax("form1:richTable:0:collapsibleSubTable:subscroller",event,{"parameters":{"form1:richTable:0:collapsibleSubTable:subscroller:page":data.page} ,"incId":"1"} )},{"digitals":{} ,"buttons":{} ,"currentPage":1} )</script></ul></td></tr><tr id="form1:richTable:0:collapsibleSubTable:sc" style="display: none;"><td><input id="form1:richTable:0:collapsibleSubTable:state" name="form1:richTable:0:collapsibleSubTable:state" type="hidden" value="0" /><input id="form1:richTable:0:collapsibleSubTable:options" name="form1:richTable:0:collapsibleSubTable:options" type="hidden" /></td></tr></tbody>]]></update></span><br>Element <b>update</b> for id=j_id1:javax.faces.ViewState:0<br><span class="rf-log-entry-msg-xml"><update id="j_id1:javax.faces.ViewState:0"><![CDATA[-7868019542578483246:-4058924891838140372]]></update></span><br>Element <b>extension</b> for id=org.richfaces.extension<br><span class="rf-log-entry-msg-xml"><extension id="org.richfaces.extension"><complete>RichFaces.jQuery(document.getElementById('form1:richTable:0:collapsibleSubTable')).subTableBridge({"optionsInput":"form1:richTable:0:collapsibleSubTable:options","formId":"form1","expandMode":"ajax","stateInput":"form1:richTable:0:collapsibleSubTable:state","eventOptions":{"incId":"1"} } );RichFaces.javascriptServiceComplete();;</complete><render>form1:richTable:0:collapsibleSubTable@body </render></extension></span><br></span> log.js:195
> Create called for sub-table-bridge of element: form1:richTable:0:collapsibleSubTable sub-table-bridge.js:42
> Create called for sub-table of element: form1:richTable:0:collapsibleSubTable sub-table.js:22
> RichFaces: richfaces.queue: ajax submit successfull log.js:195
> RichFaces: richfaces.queue: Nothing to submit log.js:195
> RichFaces: Received 'success' event from <tbody id=form1:richTable:0:collapsibleSubTable class=rf-cst ...> log.js:195
> RichFaces: Received 'complete' event from <tbody id=form1:richTable:0:collapsibleSubTable class=rf-cst ...> log.js:195
> {code}
> Note the "create" debug statements called from the plugin _create methods occur before we get to the complete event.
--
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
10 years, 2 months