[jira] [Commented] (DELTASPIKE-499) Minify javascripts on release build
[ https://issues.apache.org/jira/browse/DELTASPIKE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869344#comment-13869344 ] Thomas Andraschko commented on DELTASPIKE-499: -- +1 I will do that via a custom ResourceHandler Minify javascripts on release build --- Key: DELTASPIKE-499 URL: https://issues.apache.org/jira/browse/DELTASPIKE-499 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-499) Minify javascripts on release build
[ https://issues.apache.org/jira/browse/DELTASPIKE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869371#comment-13869371 ] Mark Struberg commented on DELTASPIKE-499: -- We do the same in MyFaces btw. You might take a look how it's done there. Minify javascripts on release build --- Key: DELTASPIKE-499 URL: https://issues.apache.org/jira/browse/DELTASPIKE-499 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (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:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-446: Assignee: Thomas Andraschko (was: Mark Struberg) 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: Thomas Andraschko 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
[ 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) Current windowhandler.js is incomaptible with PrimeFaces
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869586#comment-13869586 ] Thomas Andraschko commented on DELTASPIKE-446: -- I will talk with Cagatay and propably fix it in PrimeFaces. PrimeFaces should IMO handle both cases better. Current windowhandler.js is incomaptible with PrimeFaces 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: Thomas Andraschko 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] [Updated] (DELTASPIKE-446) Current windowhandler.js is incompatible with PrimeFaces
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-446: - Fix Version/s: 0.6 Current windowhandler.js is incompatible with PrimeFaces 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: Thomas Andraschko Fix For: 0.6 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] [Assigned] (DELTASPIKE-499) Minify javascripts on release build
[ https://issues.apache.org/jira/browse/DELTASPIKE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-499: Assignee: Thomas Andraschko Minify javascripts on release build --- Key: DELTASPIKE-499 URL: https://issues.apache.org/jira/browse/DELTASPIKE-499 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (DELTASPIKE-499) Minify javascripts on release build
[ https://issues.apache.org/jira/browse/DELTASPIKE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-499: - Fix Version/s: 0.6 Minify javascripts on release build --- Key: DELTASPIKE-499 URL: https://issues.apache.org/jira/browse/DELTASPIKE-499 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DELTASPIKE-446) Current windowhandler.js is incompatible with PrimeFaces
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869592#comment-13869592 ] Thomas Andraschko commented on DELTASPIKE-446: -- A workaround would be: p:ajaxStatus oncomplete=applyWindowId() / The problem is that you can't just call applyWindowId as all methods in windowhandler.js are private scoped. Current windowhandler.js is incompatible with PrimeFaces 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: Thomas Andraschko Fix For: 0.6 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) Current windowhandler.js is incompatible with PrimeFaces
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869771#comment-13869771 ] Gerald Turner commented on DELTASPIKE-446: -- What about ds:windowId/, any way to nest that in p:ajaxStatus/ or something similar? Current windowhandler.js is incompatible with PrimeFaces 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: Thomas Andraschko Fix For: 0.6 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) Current windowhandler.js is incompatible with PrimeFaces
[ https://issues.apache.org/jira/browse/DELTASPIKE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13869874#comment-13869874 ] Thomas Andraschko commented on DELTASPIKE-446: -- Currently not, sorry! Current windowhandler.js is incompatible with PrimeFaces 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: Thomas Andraschko Fix For: 0.6 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)
Re: Ideas on ClientWindow handling / refactoring
Mark, i understand the windowhandler.html approach but i still don't understand LAZY. You said that it's the same as URL but with some JS checks. I tried to explain my thoughts about a LAZY in my last email in the JSF - default ClientWindowRenderMode? thread. I really completely understand the logic for CLIENTWINDOW but it would be nice, if you could explain what exactly should happen on client side if the LAZY mode is used. URL is just for appending the windowId to the url's without any JS - like the default mode in CODI. If LAZY requires JS, then it's a different mode IMO because the current windowhandling also makes the target attribute of links unusable. Isn't it? 2014/1/13 Mark Struberg strub...@yahoo.de LAZY is really exactly the same as you mean with 'URL'. I just like the term 'LAZY' more than 'URL' as it explains much better what happens. Please read the very last paragraph in http://myfaces.apache.org/orchestra/multiwindow.html Afaik, this was written by Mario Ivankovic (main-brain of Orchestra) and Werner Punz (_the_ JSF spec JavaScript wizzard) back in the days when they did Apache MyFaces Orchestra. The 100% solution is the ClientWindow mode. But this has the downside of the intermediate page... LieGrue, strub On Sunday, 12 January 2014, 22:25, Thomas Andraschko andraschko.tho...@gmail.com wrote: Here is my idea about the initial refactoring on the windowhandler.js https://gist.github.com/tandraschko/3d2aa9d84f6469206ce7 I think it will need some more refactoring/fixing when we finally know what LAZY should do. But i like to structure and the single entry point via DSWindowContext#init. Also storeEvent seems the be unused? Could anyone explain this to me? 2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com (similar to what we have in codi) we can do a lazy restore in addition (if it is limited to the url/lazy mode). regards, gerhard 2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com (of course it would only be required #ifPostback) 2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com Hmm right - but we could also move windowContext#activateWindow to a AFTER_RESTORE_VIEW phase listener? AFAIK RESTORE_VIEW shouldn't touch any beans? 2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com we need to restore the window-id before the lifecycle starts. regards, gerhard 2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com but why should we keep the JS logic instead of ViewMap? Are there any drawbacks when we store it in the ViewMap? The current implementations looks soo complex, but actually it isn't that complex. So therefore i would like to get rid of not required code. 2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com as a (deactivatable) fallback the view-map would be fine (we couldn't use it in codi, because we had to support jsf 1.2.x as well) regards, gerhard 2014/1/10 Mark Struberg strub...@yahoo.de we probably should do both. LieGrue, strub - Original Message - From: Thomas Andraschko andraschko.tho...@gmail.com To: dev@deltaspike.apache.org dev@deltaspike.apache.org Cc: Sent: Friday, 10 January 2014, 16:56 Subject: Re: Ideas on ClientWindow handling / refactoring Saving the windowId for postbacks in the ViewMap, would be really a much easier, more compatible and safer way than adding hidden inputs via JS. 2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com Hi Gerhard, thats true. Therefore we added extra processing of javax.faces.ViewState+javax.faces.ClientWindow in PrimeFaces :) Don't know if Cagatay would accept that i add workarounds for DS in PrimeFaces. Therefore adding the windowId e.g. to the ViewMap would be a safer way. Regards, Thomas 2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com @thomas: with jsf 2.2+ it's different. the window-id is (/should be) also used (if enabled) to find the correct state. - any compliant request needs to include the window-id (if enabled). regards, gerhard 2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com Based on the discussion in JSF - default ClientWindowRenderMode?: struberg:
[jira] [Created] (DELTASPIKE-500) Implement ds:disableClientWindow
Thomas Andraschko created DELTASPIKE-500: Summary: Implement ds:disableClientWindow Key: DELTASPIKE-500 URL: https://issues.apache.org/jira/browse/DELTASPIKE-500 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Thomas Andraschko Fix For: 0.6 similiar to Orchestra's separateConversationContext or JSF 2.2 disableClientWindow attribute Disables the rendering of the windowId to the URLs of all child components -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (DELTASPIKE-500) Implement ds:disableClientWindow
[ https://issues.apache.org/jira/browse/DELTASPIKE-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-500: Assignee: Thomas Andraschko Implement ds:disableClientWindow Key: DELTASPIKE-500 URL: https://issues.apache.org/jira/browse/DELTASPIKE-500 Project: DeltaSpike Issue Type: New Feature Components: JSF-Module Reporter: Thomas Andraschko Assignee: Thomas Andraschko Fix For: 0.6 similiar to Orchestra's separateConversationContext or JSF 2.2 disableClientWindow attribute Disables the rendering of the windowId to the URLs of all child components -- This message was sent by Atlassian JIRA (v6.1.5#6160)
