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 javax.faces.ViewState
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
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: The windowId is added as root element to the view tree. You mean that the dsPostWindowId input is added as direct form child. Right? Posting it with default ajax options should work fine with PrimeFaces. The only difference is our partialSubmit modus, which only collects the values from the processed components. So if you only process e.g. input1 input2, the hidden inputs on the form won't processed. Updating the ViewState is a custom logic with partialSubmit. Maybe it should be handled better on PrimeFaces side but I think it would be better the store the windowId in the WindowIdComponent. It works for all cases and it don't requires any JS or compontlib compatibility. It's just stored the windowId in the ViewRoot which is always available for postbacks. Or will it have other drawbacks? About windowhandler.js/html: What about moving the whole JS stuff to the windowhandler.js? We could parse the windowhandler html string on the server and parse JSF resource includes. So we could easily include our windowhandler.js. The user can also import other resources like css. I already done this for a custom JSF 2.2 ClientWindow - works fine. I think we should also render the ClientWindowRenderMode to the client, so that the windowhandler only handles CLIENTWINDOW and not e.g. URL. I would refactor the windowhandler.js, that it must be initialized via a JS call - DSWindowContext.init(windowId, clientWindowRenderMode); We could simply render that script via our WindowIdComponentHtmlRenderer.
Re: Ideas on ClientWindow handling / refactoring
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: The windowId is added as root element to the view tree. You mean that the dsPostWindowId input is added as direct form child. Right? Posting it with default ajax options should work fine with PrimeFaces. The only difference is our partialSubmit modus, which only collects the values from the processed components. So if you only process e.g. input1 input2, the hidden inputs on the form won't processed. Updating the ViewState is a custom logic with partialSubmit. Maybe it should be handled better on PrimeFaces side but I think it would be better the store the windowId in the WindowIdComponent. It works for all cases and it don't requires any JS or compontlib compatibility. It's just stored the windowId in the ViewRoot which is always available for postbacks. Or will it have other drawbacks? About windowhandler.js/html: What about moving the whole JS stuff to the windowhandler.js? We could parse the windowhandler html string on the server and parse JSF resource includes. So we could easily include our windowhandler.js. The user can also import other resources like css. I already done this for a custom JSF 2.2 ClientWindow - works fine. I think we should also render the ClientWindowRenderMode to the client, so that the windowhandler only handles CLIENTWINDOW and not e.g. URL. I would refactor the windowhandler.js, that it must be initialized via a JS call - DSWindowContext.init(windowId, clientWindowRenderMode); We could simply render that script via our WindowIdComponentHtmlRenderer.
Re: Ideas on ClientWindow handling / refactoring
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: The windowId is added as root element to the view tree. You mean that the dsPostWindowId input is added as direct form child. Right? Posting it with default ajax options should work fine with PrimeFaces. The only difference is our partialSubmit modus, which only collects the values from the processed components. So if you only process e.g. input1 input2, the hidden inputs on the form won't processed. Updating the ViewState is a custom logic with partialSubmit. Maybe it should be handled better on PrimeFaces side but I think it would be better the store the windowId in the WindowIdComponent. It works for all cases and it don't requires any JS or compontlib compatibility. It's just stored the windowId in the ViewRoot which is always available for postbacks. Or will it have other drawbacks? About windowhandler.js/html: What about moving the whole JS stuff to the windowhandler.js? We could parse the windowhandler html string on the server and parse JSF resource includes. So we could easily include our windowhandler.js. The user can also import other resources like css. I already done this for a custom JSF 2.2 ClientWindow - works fine. I think we should also render the ClientWindowRenderMode to the client, so that the windowhandler only handles CLIENTWINDOW and not e.g. URL. I would refactor the windowhandler.js, that it must be initialized
Re: Ideas on ClientWindow handling / refactoring
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: The windowId is added as root element to the view tree. You mean that the dsPostWindowId input is added as direct form child. Right? Posting it with default ajax options should work fine with PrimeFaces. The only difference is our partialSubmit modus, which only collects the values from the processed components. So if you only process e.g. input1 input2, the hidden inputs on the form won't processed. Updating the ViewState is a custom logic with partialSubmit. Maybe it should be handled better on PrimeFaces side but I think it would be better the store the windowId in the WindowIdComponent. It works for all cases and it don't requires any JS or compontlib compatibility. It's just stored the windowId in the ViewRoot which is always available for postbacks. Or will it have other drawbacks? About windowhandler.js/html: What about moving the whole JS stuff to the windowhandler.js? We could parse the windowhandler html string on the server and parse JSF resource includes. So we could easily include our windowhandler.js
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
Re: Ideas on ClientWindow handling / refactoring
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: The windowId is added as root element to the view tree. You mean that the dsPostWindowId input is added as direct form child. Right? Posting it with default ajax options should work fine with PrimeFaces. The only difference is our partialSubmit modus, which only collects the values from the processed components. So if you only process e.g. input1 input2, the hidden inputs on the form won't processed. Updating the ViewState is a custom logic with partialSubmit. Maybe it should be handled better on PrimeFaces side but I think it would be better the store the windowId in the WindowIdComponent. It works for all cases and it don't requires any JS or compontlib compatibility. It's just stored the windowId in the ViewRoot which is always available for postbacks. Or will it have other drawbacks? About windowhandler.js/html: What about moving the whole JS stuff to the windowhandler.js? We could parse the windowhandler html string on the server and parse JSF resource includes. So we could easily include our windowhandler.js. The user can also import other resources like css. I already done this for a custom JSF 2.2 ClientWindow - works fine. I think we should also render the ClientWindowRenderMode to the client, so that the windowhandler only
Re: Ideas on ClientWindow handling / refactoring
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: The windowId is added as root element to the view tree. You mean that the dsPostWindowId input is added as direct form child. Right? Posting it with default ajax options should work fine with PrimeFaces. The only difference is our partialSubmit modus, which only collects the values from the processed components. So if you only process e.g. input1 input2, the hidden inputs on the form won't processed. Updating the ViewState is a custom logic with partialSubmit. Maybe it should be handled better on PrimeFaces side but I think it would be better the store the windowId in the WindowIdComponent. It works for all cases and it don't requires any JS or compontlib compatibility. It's just stored the windowId in the ViewRoot which is always available for postbacks. Or will it have other drawbacks? About windowhandler.js/html: What about moving the whole JS stuff to the windowhandler.js? We could parse the windowhandler html string on the server and parse JSF resource includes. So we could easily include our windowhandler.js. The user can also import other resources like css. I already done this for a custom JSF 2.2 ClientWindow - works fine. I think we should also render the ClientWindowRenderMode to the client, so that the windowhandler only handles CLIENTWINDOW and not e.g. URL. I would refactor the windowhandler.js, that it must be initialized via a JS call - DSWindowContext.init(windowId, clientWindowRenderMode); We could simply render that script via our WindowIdComponentHtmlRenderer.
Re: Ideas on ClientWindow handling / refactoring
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: The windowId is added as root element to the view tree. You mean that the dsPostWindowId input is added as direct form child. Right? Posting it with default ajax options should work fine with PrimeFaces. The only difference is our partialSubmit modus, which only collects the values from the processed components. So if you only process e.g. input1 input2, the hidden inputs on the form won't processed. Updating the ViewState is a custom logic with partialSubmit. Maybe it should be handled better on PrimeFaces side but I think it would be better the store the windowId in the WindowIdComponent. It works for all cases and it don't requires any JS or compontlib compatibility. It's just stored the windowId in the ViewRoot which is always available for postbacks. Or will it have other drawbacks? About windowhandler.js/html: What about moving the whole JS stuff to the windowhandler.js? We could parse the windowhandler html string on the server and parse JSF resource includes. So we could easily include our windowhandler.js. The user can also import other resources like css. I already done this for a custom JSF 2.2 ClientWindow - works fine. I think we should also render the ClientWindowRenderMode to the client, so that the windowhandler only handles CLIENTWINDOW and not e.g. URL. I would refactor the windowhandler.js, that it must be initialized via a JS call - DSWindowContext.init(windowId, clientWindowRenderMode); We could simply render that script via our WindowIdComponentHtmlRenderer.
Re: Ideas on ClientWindow handling / refactoring
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: The windowId is added as root element to the view tree. You mean that the dsPostWindowId input is added as direct form child. Right? Posting it with default ajax options should work fine with PrimeFaces. The only difference is our partialSubmit modus, which only collects the values from the processed components. So if you only process e.g. input1 input2, the hidden inputs on the form won't processed. Updating the ViewState is a custom logic with partialSubmit. Maybe it should be handled better on PrimeFaces side but I think it would be better the store the windowId in the WindowIdComponent. It works for all cases and it don't requires any JS or compontlib compatibility. It's just stored the windowId in the ViewRoot which is always available for postbacks. Or will it have other drawbacks? About windowhandler.js/html: What about moving the whole JS stuff to the windowhandler.js? We could parse the windowhandler html string on the server and parse JSF resource includes. So we could easily include our windowhandler.js. The user can also import other resources like css. I already done this for a custom JSF 2.2 ClientWindow - works fine. I think we should also render the ClientWindowRenderMode to the client, so that the windowhandler only handles CLIENTWINDOW and not e.g. URL. I would refactor the windowhandler.js, that it must be initialized via a JS call - DSWindowContext.init(windowId, clientWindowRenderMode); We could simply render that script via our WindowIdComponentHtmlRenderer.
Re: Ideas on ClientWindow handling / refactoring
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: The windowId is added as root element to the view tree. You mean that the dsPostWindowId input is added as direct form child. Right? Posting it with default ajax options should work fine with PrimeFaces. The only difference is our partialSubmit modus, which only collects the values from the processed components. So if you only process e.g. input1 input2, the hidden inputs on the form won't processed. Updating the ViewState is a custom logic with partialSubmit. Maybe it should be handled better on PrimeFaces side but I think it would be better the store the windowId in the WindowIdComponent. It works for all cases and it don't requires any JS or compontlib compatibility. It's just stored the windowId in the ViewRoot which is always available for postbacks. Or will it have other drawbacks? About windowhandler.js/html: What about moving the whole JS stuff to the windowhandler.js? We could parse the windowhandler html string on the server and parse JSF resource includes. So we could easily include our windowhandler.js. The user can also import other resources like css. I already done this for a custom JSF 2.2 ClientWindow - works fine. I think we should also render the ClientWindowRenderMode to the client, so that the windowhandler only handles CLIENTWINDOW and not e.g. URL. I would refactor the windowhandler.js, that it must be initialized via a JS call - DSWindowContext.init(windowId, clientWindowRenderMode); We could simply render that script via our WindowIdComponentHtmlRenderer.
Re: Ideas on ClientWindow handling / refactoring
(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: The windowId is added as root element to the view tree. You mean that the dsPostWindowId input is added as direct form child. Right? Posting it with default ajax options should work fine with PrimeFaces. The only difference is our partialSubmit modus, which only collects the values from the processed components. So if you only process e.g. input1 input2, the hidden inputs on the form won't processed. Updating the ViewState is a custom logic with partialSubmit. Maybe it should be handled better on PrimeFaces side but I think it would be better the store the windowId in the WindowIdComponent. It works for all cases and it don't requires any JS or compontlib compatibility. It's just stored the windowId in the ViewRoot which is always available for postbacks. Or will it have other drawbacks? About windowhandler.js/html: What about moving the whole JS stuff to the windowhandler.js? We could parse the windowhandler html string on the server and parse JSF resource includes. So we could easily include our windowhandler.js. The user can also import other resources like css. I already done this for a custom JSF 2.2 ClientWindow - works fine. I think we should also render the ClientWindowRenderMode to the client, so that the windowhandler only handles CLIENTWINDOW and not e.g. URL. I would refactor the windowhandler.js, that it must be initialized via a JS call - DSWindowContext.init(windowId, clientWindowRenderMode); We could simply render that script via our WindowIdComponentHtmlRenderer.
