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

2014-01-13 Thread Thomas Andraschko (JIRA)

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

Thomas Andraschko commented on DELTASPIKE-446:
--

It's related how DS handles the windowId.
It automatically attachs a hiddenInput in each form.

2 possible failures:
- the hiddenInput won't be posted when PF partialSubmit is activated
- after the ajax update, the registered handler for readding the windowId to 
the form won't be called, as jsf.ajax.addOnEvent doesn't work with PF

I will take care of this.

 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
Assignee: Mark Struberg

 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.5#6160)


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

2013-11-21 Thread Gerald Turner (JIRA)

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

Gerald Turner commented on DELTASPIKE-446:
--

Comparing two separate applications, both having the same delete confirmation 
mechanism, but one using CODI, and other DeltaSpike, I see one glaring 
difference: all the XHR POST's from the CODI app have ?windowId=n on their 
request URI's, whereas the DeltaSpike app POST request URI's are bare of any 
parameters.

 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)