Re: Ideas on ClientWindow handling / refactoring
I think i understand know what lazy should do... Our windowhandler.js just checks if window.name is empty, removes the windowId and redirects to the same url without a windowId. But we must also do another check if the mode is LAZY because it currently don't validate the windowId. If you a page in a new tab - test.xhtml?windowId=1 it checks that the window.name is empty and redirects to test.xhtml?windowId= The server will now redirect to: text.xhtml?windowId=someNewAndValidWIndowId What appens now if you open this in the same tab: test.xhtml?windowId=3 nothing! #assertWindowId must also take care of this. What should happen? Reload/redirect via the windowId stored in window.nameor doing a redirect without windowId (assigning a new windowId to the tab)? I would rename URL to LAZY (merge these modes) and fix this small bug above. Any objections? 2014/1/13 Thomas Andraschko andraschko.tho...@gmail.com 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
Re: Ideas on ClientWindow handling / refactoring
imo we should keep one mode which works without js. regards, gerhard 2014/1/14 Thomas Andraschko andraschko.tho...@gmail.com I think i understand know what lazy should do... Our windowhandler.js just checks if window.name is empty, removes the windowId and redirects to the same url without a windowId. But we must also do another check if the mode is LAZY because it currently don't validate the windowId. If you a page in a new tab - test.xhtml?windowId=1 it checks that the window.name is empty and redirects to test.xhtml?windowId= The server will now redirect to: text.xhtml?windowId=someNewAndValidWIndowId What appens now if you open this in the same tab: test.xhtml?windowId=3 nothing! #assertWindowId must also take care of this. What should happen? Reload/redirect via the windowId stored in window.nameor doing a redirect without windowId (assigning a new windowId to the tab)? I would rename URL to LAZY (merge these modes) and fix this small bug above. Any objections? 2014/1/13 Thomas Andraschko andraschko.tho...@gmail.com 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
Re: Ideas on ClientWindow handling / refactoring
Hi Gerhard, LAZY mode without adding ds:windowId will exactly work like URL. But it will never have a chance to detect new windows. We could also keep LAZY and URL, doesn't matter for me :) The main goal of the last email to clarify what the LAZY script part should do and that it currently has an bug. Regards, Thomas 2014/1/14 Gerhard Petracek gerhard.petra...@gmail.com imo we should keep one mode which works without js. regards, gerhard 2014/1/14 Thomas Andraschko andraschko.tho...@gmail.com I think i understand know what lazy should do... Our windowhandler.js just checks if window.name is empty, removes the windowId and redirects to the same url without a windowId. But we must also do another check if the mode is LAZY because it currently don't validate the windowId. If you a page in a new tab - test.xhtml?windowId=1 it checks that the window.name is empty and redirects to test.xhtml?windowId= The server will now redirect to: text.xhtml?windowId=someNewAndValidWIndowId What appens now if you open this in the same tab: test.xhtml?windowId=3 nothing! #assertWindowId must also take care of this. What should happen? Reload/redirect via the windowId stored in window.nameor doing a redirect without windowId (assigning a new windowId to the tab)? I would rename URL to LAZY (merge these modes) and fix this small bug above. Any objections? 2014/1/13 Thomas Andraschko andraschko.tho...@gmail.com 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
Re: Ideas on ClientWindow handling / refactoring
+1 regards, gerhard 2014/1/14 Thomas Andraschko andraschko.tho...@gmail.com Hi Gerhard, LAZY mode without adding ds:windowId will exactly work like URL. But it will never have a chance to detect new windows. We could also keep LAZY and URL, doesn't matter for me :) The main goal of the last email to clarify what the LAZY script part should do and that it currently has an bug. Regards, Thomas 2014/1/14 Gerhard Petracek gerhard.petra...@gmail.com imo we should keep one mode which works without js. regards, gerhard 2014/1/14 Thomas Andraschko andraschko.tho...@gmail.com I think i understand know what lazy should do... Our windowhandler.js just checks if window.name is empty, removes the windowId and redirects to the same url without a windowId. But we must also do another check if the mode is LAZY because it currently don't validate the windowId. If you a page in a new tab - test.xhtml?windowId=1 it checks that the window.name is empty and redirects to test.xhtml?windowId= The server will now redirect to: text.xhtml?windowId=someNewAndValidWIndowId What appens now if you open this in the same tab: test.xhtml?windowId=3 nothing! #assertWindowId must also take care of this. What should happen? Reload/redirect via the windowId stored in window.nameor doing a redirect without windowId (assigning a new windowId to the tab)? I would rename URL to LAZY (merge these modes) and fix this small bug above. Any objections? 2014/1/13 Thomas Andraschko andraschko.tho...@gmail.com 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
[jira] [Resolved] (DELTASPIKE-498) Deltaspike 0.6-SNAPSHOT failing on JBoss 7 and Wildfly
[
https://issues.apache.org/jira/browse/DELTASPIKE-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek resolved DELTASPIKE-498.
-
Resolution: Not A Problem
Deltaspike 0.6-SNAPSHOT failing on JBoss 7 and Wildfly
--
Key: DELTASPIKE-498
URL: https://issues.apache.org/jira/browse/DELTASPIKE-498
Project: DeltaSpike
Issue Type: Bug
Components: Build
Affects Versions: 0.6
Environment: Ubuntu , Eclipse IDE(Kepler) , Java 7
Reporter: Paa Kojo Konduah Amos
I set out to try the Data Module of Deltaspike. So i have the following for
example;
@Repository
public interface SomeInterface extends EntityRepositorySomeEntity, Long{}
Now according to the online documentation, it reads ,The implementation of
the method is done automatically by the CDI extension.
So, i try to inject this SomeInterface into a controller, thinking the
implementation is done automatically. Eclipse warns that (No bean is eligible
for injection to the injection point [JSR-299 ยง5.2.1]).
So i migrate from 0.5 to 0.6 thinking that would be resolved. Still i get
that and when i try to deploy in JBoss 7 or Wild fly, please find below the
error stack.
05:33:18,226 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1)
JBAS015876: Starting deployment of geniidm.war
05:33:18,685 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4)
MSC1: Failed to start service
jboss.deployment.unit.geniidm.war.STRUCTURE:
org.jboss.msc.service.StartException in service
jboss.deployment.unit.geniidm.war.STRUCTURE: Failed to process phase
STRUCTURE of deployment geniidm.war
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119)
[jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
[jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
[jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_45]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException:
org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018037:
Failed to process WEB-INF/lib: /home/pkkamos/Application
Servers/Brontes-Master/standalone/deployments/geniidm.war/WEB-INF/lib/deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar
at
org.jboss.as.web.deployment.WarStructureDeploymentProcessor.deploy(WarStructureDeploymentProcessor.java:120)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113)
[jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
... 5 more
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException:
JBAS018037: Failed to process WEB-INF/lib: /home/pkkamos/Application
Servers/Brontes-Master/standalone/deployments/geniidm.war/WEB-INF/lib/deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar
at
org.jboss.as.web.deployment.WarStructureDeploymentProcessor.createWebInfLibResources(WarStructureDeploymentProcessor.java:175)
at
org.jboss.as.web.deployment.WarStructureDeploymentProcessor.createResourceRoots(WarStructureDeploymentProcessor.java:153)
at
org.jboss.as.web.deployment.WarStructureDeploymentProcessor.deploy(WarStructureDeploymentProcessor.java:114)
... 6 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.7.0_45]
at java.util.zip.ZipFile.init(ZipFile.java:215) [rt.jar:1.7.0_45]
at java.util.zip.ZipFile.init(ZipFile.java:145) [rt.jar:1.7.0_45]
at java.util.jar.JarFile.init(JarFile.java:153) [rt.jar:1.7.0_45]
at java.util.jar.JarFile.init(JarFile.java:117) [rt.jar:1.7.0_45]
at org.jboss.vfs.spi.JavaZipFileSystem.init(JavaZipFileSystem.java:97)
at org.jboss.vfs.spi.JavaZipFileSystem.init(JavaZipFileSystem.java:83)
at org.jboss.vfs.VFS.mountZip(VFS.java:408)
at org.jboss.vfs.VFS.mountZip(VFS.java:434)
at
org.jboss.as.web.deployment.WarStructureDeploymentProcessor.createWebInfLibResources(WarStructureDeploymentProcessor.java:170)
... 8 more
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (DELTASPIKE-502) Finish LAZY ClientWindowRenderMode
Thomas Andraschko created DELTASPIKE-502: Summary: Finish LAZY ClientWindowRenderMode Key: DELTASPIKE-502 URL: https://issues.apache.org/jira/browse/DELTASPIKE-502 Project: DeltaSpike Issue Type: Improvement Components: JSF-Module Affects Versions: 0.6 Reporter: Thomas Andraschko Assignee: Thomas Andraschko -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Ideas on ClientWindow handling / refactoring
+1 for keeping URL and LAZY? :) 2014/1/14 Gerhard Petracek gerhard.petra...@gmail.com +1 regards, gerhard 2014/1/14 Thomas Andraschko andraschko.tho...@gmail.com Hi Gerhard, LAZY mode without adding ds:windowId will exactly work like URL. But it will never have a chance to detect new windows. We could also keep LAZY and URL, doesn't matter for me :) The main goal of the last email to clarify what the LAZY script part should do and that it currently has an bug. Regards, Thomas 2014/1/14 Gerhard Petracek gerhard.petra...@gmail.com imo we should keep one mode which works without js. regards, gerhard 2014/1/14 Thomas Andraschko andraschko.tho...@gmail.com I think i understand know what lazy should do... Our windowhandler.js just checks if window.name is empty, removes the windowId and redirects to the same url without a windowId. But we must also do another check if the mode is LAZY because it currently don't validate the windowId. If you a page in a new tab - test.xhtml?windowId=1 it checks that the window.name is empty and redirects to test.xhtml?windowId= The server will now redirect to: text.xhtml?windowId=someNewAndValidWIndowId What appens now if you open this in the same tab: test.xhtml?windowId=3 nothing! #assertWindowId must also take care of this. What should happen? Reload/redirect via the windowId stored in window.nameor doing a redirect without windowId (assigning a new windowId to the tab)? I would rename URL to LAZY (merge these modes) and fix this small bug above. Any objections? 2014/1/13 Thomas Andraschko andraschko.tho...@gmail.com 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
Re: Ideas on ClientWindow handling / refactoring
+1 for merging them and without the js it still works (like the default-mode of codi). regards, gerhard 2014/1/14 Thomas Andraschko andraschko.tho...@gmail.com +1 for keeping URL and LAZY? :) 2014/1/14 Gerhard Petracek gerhard.petra...@gmail.com +1 regards, gerhard 2014/1/14 Thomas Andraschko andraschko.tho...@gmail.com Hi Gerhard, LAZY mode without adding ds:windowId will exactly work like URL. But it will never have a chance to detect new windows. We could also keep LAZY and URL, doesn't matter for me :) The main goal of the last email to clarify what the LAZY script part should do and that it currently has an bug. Regards, Thomas 2014/1/14 Gerhard Petracek gerhard.petra...@gmail.com imo we should keep one mode which works without js. regards, gerhard 2014/1/14 Thomas Andraschko andraschko.tho...@gmail.com I think i understand know what lazy should do... Our windowhandler.js just checks if window.name is empty, removes the windowId and redirects to the same url without a windowId. But we must also do another check if the mode is LAZY because it currently don't validate the windowId. If you a page in a new tab - test.xhtml?windowId=1 it checks that the window.name is empty and redirects to test.xhtml?windowId= The server will now redirect to: text.xhtml?windowId=someNewAndValidWIndowId What appens now if you open this in the same tab: test.xhtml?windowId=3 nothing! #assertWindowId must also take care of this. What should happen? Reload/redirect via the windowId stored in window.nameor doing a redirect without windowId (assigning a new windowId to the tab)? I would rename URL to LAZY (merge these modes) and fix this small bug above. Any objections? 2014/1/13 Thomas Andraschko andraschko.tho...@gmail.com 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
[jira] [Assigned] (DELTASPIKE-118) custom port for jbossas-build-managed-7
[
https://issues.apache.org/jira/browse/DELTASPIKE-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Kaltepoth reassigned DELTASPIKE-118:
--
Assignee: Christian Kaltepoth (was: Mark Struberg)
We could use the {{jboss.socket.binding.port-offset}} system property for this.
I'll give it a try.
custom port for jbossas-build-managed-7
---
Key: DELTASPIKE-118
URL: https://issues.apache.org/jira/browse/DELTASPIKE-118
Project: DeltaSpike
Issue Type: Task
Components: Tests
Affects Versions: 0.1-incubating
Reporter: Gerhard Petracek
Assignee: Christian Kaltepoth
Fix For: 0.6
we need a custom port to run in on jenkins.
( blocked by https://issues.jboss.org/browse/AS7-1036 )
we could replace standalone.xml after the unpack process (in
process-test-classes)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
