You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "Gerald Turner (JIRA)" <ji...@apache.org> on 2013/11/21 22:50:36 UTC

[jira] [Commented] (DELTASPIKE-446) windowhandler.js doesn't handle nested ajax calls

    [ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13829382#comment-13829382 ] 

Gerald Turner commented on DELTASPIKE-446:
------------------------------------------

I had thought that perhaps <p:dialog dynamic="true".../> may had been the culprit.  The attribute is described as "lazy loading of the content with ajax", sure enough there's an extra XHR request when the dialog is updated (and does include the dsPostWindowId param).  However when disabling this feature, the bug still remains.


> windowhandler.js doesn't handle nested ajax calls
> -------------------------------------------------
>
>                 Key: DELTASPIKE-446
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-446
>             Project: DeltaSpike
>          Issue Type: Bug
>          Components: JSF-Module
>    Affects Versions: 0.5
>         Environment: JBoss AS 7.2 / EAP 6.1
>            Reporter: Gerald Turner
>
> I get the exception "org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type org.apache.deltaspike.core.api.scope.WindowScoped" from a commandButton ajax call that is nested in a form that had been updated by another commandLink ajax call.
> These pages had been working with CODI.
> Scenario is a "delete confirmation" dialog, using PrimeFaces (p:dialog dynamic="true" may be the culprit):
> I have a p:dataTable, with a column with a p:commandLink ("Delete"), this link updates a p:dialog ("Are you sure?").  The p:dialog contains a p:commandButton ("Yes").
> Both the contents of the dialog and the actionListener of the commandButton access a @WindowScoped bean.
> Tracing the XHR POSTs, I see dsPostWindowId being sent when the first delete button is click, and it is not present with the final confirmation button is clicked.
> Scrutinizing over windowhandler.js, I can imagine that when the page is first loaded, 'jsf.ajax.addOnEvent(ajaxOnClick)' works it's magic and 'applyWindowId()' is effective for the first ajax call, but then the page has new elements which have not been decorated, so the second/nested ajax call doesn't have the dsPostWindowId parameter.



--
This message was sent by Atlassian JIRA
(v6.1#6144)