Re: JSF - default ClientWindowRenderMode?
mark needs to tell, if the lazy-mode should work already. regards, gerhard 2014/1/10 Thomas Andraschko > No problem! I would just like to understand all your ideas before doing > anything further changes :) > > But to be honest, i still don't understand how LAZY should work. > > What will happen on a GET request with windowId? > The page will be rendered normally and the windowhandler will check the > window.name and compare with the current windowId request param. > If it doesn't match -> refresh the page with the windowId from > window.nameOR should it generate a new one with a refresh without > windowId? > > It's clear without windowId -> create new id and do a initial redirect + > set windowId as window.name > > > > > 2014/1/10 Mark Struberg > > > > > > > btw, thanks for bringing those questions up on the list - this is surely > > not documented well enough ;) > > Also it's really a hard thing to get right alone, so thanks for pushing > > this! > > > > LieGrue, > > strub > > > > > > > > > > > > >____________________ > > > From: Thomas Andraschko > > >To: Mark Struberg > > >Cc: "dev@deltaspike.apache.org" > > >Sent: Friday, 10 January 2014, 14:18 > > >Subject: Re: JSF - default ClientWindowRenderMode? > > > > > > > > >2014/1/10 Mark Struberg > > > > > >> Otherwise one could just open the same bookmark URL with the > > &windowId=123 > > >> parameter in multiple browser tabs and you would again share the state > > >> between them. > > > > > > > > >Thats true but as far as i understand, we can't avoid such situations > > >without streaming the windowhandler etc. > > > > > >Maybe you can explain LAZY a little bit more + some cases. > > > > > > > > > > > >2014/1/10 Mark Struberg > > > > > >> > > >> > > >> It's a bit more complicated. > > >> > > >> In case of any mismatch (regardless if window.name is empty or just > > >> different from the windowId url parameter) you need to trigger a more > > >> complex handling to properly set the window.name. > > >> > > >> Otherwise one could just open the same bookmark URL with the > > &windowId=123 > > >> parameter in multiple browser tabs and you would again share the state > > >> between them. > > >> > > >> Actually the windowhandler.js script should contain all the necessary > > >> handling code already. > > >> > > >> LieGrue, > > >> strub > > >> > > >> > > >> > > >> > > >> > > >> > > > >> > From: Thomas Andraschko > > >> >To: dev@deltaspike.apache.org; Mark Struberg > > >> >Sent: Friday, 10 January 2014, 13:58 > > >> >Subject: Re: JSF - default ClientWindowRenderMode? > > >> > > > >> > > > >> > > > >> >Ok would be fine for me, too! > > >> >The script for the LAZY mode will just do: > > >> >- if window.name == undefined -> window.name == windowId > > >> >- if window.name != undefined && window.name != windowId -> redirect > > >> with removed windowId url param > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> >2014/1/10 Mark Struberg > > >> > > > >> > > > >> >> > > >> >>I'm fine with making the 'URL' mode the default. I still like the > name > > >> 'LAZY' better though ;) > > >> >> > > >> >>Even the CLIENT_WINDOW mode will add a windowId parameter to the URL > > in > > >> some cases! > > >> >>The name 'LAZY' just makes it more clear that the > > >> wrong-browser-tab-detection is only done lazily and the initial > request > > >> might trash beans... > > >> >> > > >> >> > > >> >> > > >> >>LieGrue, > > >> >>strub > > >> >> > > >> >> > > >> >>> > > >> >>> From: Thomas Andraschko > > >> &g
Re: JSF - default ClientWindowRenderMode?
No problem! I would just like to understand all your ideas before doing anything further changes :) But to be honest, i still don't understand how LAZY should work. What will happen on a GET request with windowId? The page will be rendered normally and the windowhandler will check the window.name and compare with the current windowId request param. If it doesn't match -> refresh the page with the windowId from window.nameOR should it generate a new one with a refresh without windowId? It's clear without windowId -> create new id and do a initial redirect + set windowId as window.name 2014/1/10 Mark Struberg > > > btw, thanks for bringing those questions up on the list - this is surely > not documented well enough ;) > Also it's really a hard thing to get right alone, so thanks for pushing > this! > > LieGrue, > strub > > > > > > > > > From: Thomas Andraschko > >To: Mark Struberg > >Cc: "dev@deltaspike.apache.org" > >Sent: Friday, 10 January 2014, 14:18 > >Subject: Re: JSF - default ClientWindowRenderMode? > > > > > >2014/1/10 Mark Struberg > > > >> Otherwise one could just open the same bookmark URL with the > &windowId=123 > >> parameter in multiple browser tabs and you would again share the state > >> between them. > > > > > >Thats true but as far as i understand, we can't avoid such situations > >without streaming the windowhandler etc. > > > >Maybe you can explain LAZY a little bit more + some cases. > > > > > > > >2014/1/10 Mark Struberg > > > >> > >> > >> It's a bit more complicated. > >> > >> In case of any mismatch (regardless if window.name is empty or just > >> different from the windowId url parameter) you need to trigger a more > >> complex handling to properly set the window.name. > >> > >> Otherwise one could just open the same bookmark URL with the > &windowId=123 > >> parameter in multiple browser tabs and you would again share the state > >> between them. > >> > >> Actually the windowhandler.js script should contain all the necessary > >> handling code already. > >> > >> LieGrue, > >> strub > >> > >> > >> > >> > >> > >> > > >> > From: Thomas Andraschko > >> >To: dev@deltaspike.apache.org; Mark Struberg > >> >Sent: Friday, 10 January 2014, 13:58 > >> >Subject: Re: JSF - default ClientWindowRenderMode? > >> > > >> > > >> > > >> >Ok would be fine for me, too! > >> >The script for the LAZY mode will just do: > >> >- if window.name == undefined -> window.name == windowId > >> >- if window.name != undefined && window.name != windowId -> redirect > >> with removed windowId url param > >> > > >> > > >> > > >> > > >> > > >> > > >> >2014/1/10 Mark Struberg > >> > > >> > > >> >> > >> >>I'm fine with making the 'URL' mode the default. I still like the name > >> 'LAZY' better though ;) > >> >> > >> >>Even the CLIENT_WINDOW mode will add a windowId parameter to the URL > in > >> some cases! > >> >>The name 'LAZY' just makes it more clear that the > >> wrong-browser-tab-detection is only done lazily and the initial request > >> might trash beans... > >> >> > >> >> > >> >> > >> >>LieGrue, > >> >>strub > >> >> > >> >> > >> >>> > >> >>> From: Thomas Andraschko > >> >>>To: dev@deltaspike.apache.org; Mark Struberg > >> >>>Sent: Friday, 10 January 2014, 13:43 > >> >> > >> >>>Subject: Re: JSF - default ClientWindowRenderMode? > >> >>> > >> >>> > >> >>>Ok! So keeping the new URL mode, which is indentical to the deafult > CODI > >> >>>mode, makes sense for me. > >> >>> > >> >>>I will open another thread for the details here and some ideas about > >> >>>refactoring from my side. > >> >>> > >> >>>What do think about the default mode Mark? Should it be URL like its > in
Re: JSF - default ClientWindowRenderMode?
btw, thanks for bringing those questions up on the list - this is surely not documented well enough ;) Also it's really a hard thing to get right alone, so thanks for pushing this! LieGrue, strub > > From: Thomas Andraschko >To: Mark Struberg >Cc: "dev@deltaspike.apache.org" >Sent: Friday, 10 January 2014, 14:18 >Subject: Re: JSF - default ClientWindowRenderMode? > > >2014/1/10 Mark Struberg > >> Otherwise one could just open the same bookmark URL with the &windowId=123 >> parameter in multiple browser tabs and you would again share the state >> between them. > > >Thats true but as far as i understand, we can't avoid such situations >without streaming the windowhandler etc. > >Maybe you can explain LAZY a little bit more + some cases. > > > >2014/1/10 Mark Struberg > >> >> >> It's a bit more complicated. >> >> In case of any mismatch (regardless if window.name is empty or just >> different from the windowId url parameter) you need to trigger a more >> complex handling to properly set the window.name. >> >> Otherwise one could just open the same bookmark URL with the &windowId=123 >> parameter in multiple browser tabs and you would again share the state >> between them. >> >> Actually the windowhandler.js script should contain all the necessary >> handling code already. >> >> LieGrue, >> strub >> >> >> >> >> >> > >> > From: Thomas Andraschko >> >To: dev@deltaspike.apache.org; Mark Struberg >> >Sent: Friday, 10 January 2014, 13:58 >> >Subject: Re: JSF - default ClientWindowRenderMode? >> > >> > >> > >> >Ok would be fine for me, too! >> >The script for the LAZY mode will just do: >> >- if window.name == undefined -> window.name == windowId >> >- if window.name != undefined && window.name != windowId -> redirect >> with removed windowId url param >> > >> > >> > >> > >> > >> > >> >2014/1/10 Mark Struberg >> > >> > >> >> >> >>I'm fine with making the 'URL' mode the default. I still like the name >> 'LAZY' better though ;) >> >> >> >>Even the CLIENT_WINDOW mode will add a windowId parameter to the URL in >> some cases! >> >>The name 'LAZY' just makes it more clear that the >> wrong-browser-tab-detection is only done lazily and the initial request >> might trash beans... >> >> >> >> >> >> >> >>LieGrue, >> >>strub >> >> >> >> >> >>> >> >>> From: Thomas Andraschko >> >>>To: dev@deltaspike.apache.org; Mark Struberg >> >>>Sent: Friday, 10 January 2014, 13:43 >> >> >> >>>Subject: Re: JSF - default ClientWindowRenderMode? >> >>> >> >>> >> >>>Ok! So keeping the new URL mode, which is indentical to the deafult CODI >> >>>mode, makes sense for me. >> >>> >> >>>I will open another thread for the details here and some ideas about >> >>>refactoring from my side. >> >>> >> >>>What do think about the default mode Mark? Should it be URL like its in >> >>>CODI? >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>>2014/1/10 Mark Struberg >> >>> >> >>>> right. >> >>>> >> >>>> Basically you have to distinguish the two sides of the story. >> >>>> >> >>>> a.) how does the browser handle the windowId >> >>>> b.) how does any servlet part detect the windodwId and how to detect >> that >> >>>> it is missing (and should be there) >> >>>> >> >>>> The windowId is added as root element to the view tree. I know that >> this >> >>>> did not work with the 'old' PrimeFaces proprietary ajax handling. But >> i was >> >>>> under the impression that this was long time fixed since then when >> Cagatay >> >>>> switched to standard jsf.js AJAX functions. Or is this still not >> working? >> >>&
Re: JSF - default ClientWindowRenderMode?
we can - if we detect such a case we generate a fresh windowId + javascript code which forces setting the window.name. Same applies atm if the server got hit by a GET without a windowId parameter. In this case we did an 'initial redirect' in CODI. So even the LAZY approach could result in having multiple GET if the windowId does not fit. The difference is that you do not get it for _every_ GET, but the downside is that you might trash bean state on the initial request. LieGrue, strub > > From: Thomas Andraschko >To: Mark Struberg >Cc: "dev@deltaspike.apache.org" >Sent: Friday, 10 January 2014, 14:18 >Subject: Re: JSF - default ClientWindowRenderMode? > > > >2014/1/10 Mark Struberg > >Otherwise one could just open the same bookmark URL with the &windowId=123 parameter in multiple browser tabs and you would again share the state between them. > >Thats true but as far as i understand, we can't avoid such situations without >streaming the windowhandler etc. > > >Maybe you can explain LAZY a little bit more + some cases. > > > >2014/1/10 Mark Struberg > > >> >>It's a bit more complicated. >> >>In case of any mismatch (regardless if window.name is empty or just different >>from the windowId url parameter) you need to trigger a more complex handling >>to properly set the window.name. >> >>Otherwise one could just open the same bookmark URL with the &windowId=123 >>parameter in multiple browser tabs and you would again share the state >>between them. >> >>Actually the windowhandler.js script should contain all the necessary >>handling code already. >> >> >>LieGrue, >>strub >> >> >> >> >> >>> >>> From: Thomas Andraschko >>>To: dev@deltaspike.apache.org; Mark Struberg >>>Sent: Friday, 10 January 2014, 13:58 >> >>>Subject: Re: JSF - default ClientWindowRenderMode? >>> >>> >>> >>>Ok would be fine for me, too! >>>The script for the LAZY mode will just do: >>>- if window.name == undefined -> window.name == windowId >>>- if window.name != undefined && window.name != windowId -> redirect with >>>removed windowId url param >>> >>> >>> >>> >>> >>> >>>2014/1/10 Mark Struberg >>> >>> >>>> >>>>I'm fine with making the 'URL' mode the default. I still like the name >>>>'LAZY' better though ;) >>>> >>>>Even the CLIENT_WINDOW mode will add a windowId parameter to the URL in >>>>some cases! >>>>The name 'LAZY' just makes it more clear that the >>>>wrong-browser-tab-detection is only done lazily and the initial request >>>>might trash beans... >>>> >>>> >>>> >>>>LieGrue, >>>>strub >>>> >>>> >>>>> >>>>> From: Thomas Andraschko >>>>>To: dev@deltaspike.apache.org; Mark Struberg >>>>>Sent: Friday, 10 January 2014, 13:43 >>>> >>>>>Subject: Re: JSF - default ClientWindowRenderMode? >>>>> >>>>> >>>>>Ok! So keeping the new URL mode, which is indentical to the deafult CODI >>>>>mode, makes sense for me. >>>>> >>>>>I will open another thread for the details here and some ideas about >>>>>refactoring from my side. >>>>> >>>>>What do think about the default mode Mark? Should it be URL like its in >>>>>CODI? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>2014/1/10 Mark Struberg >>>>> >>>>>> right. >>>>>> >>>>>> Basically you have to distinguish the two sides of the story. >>>>>> >>>>>> a.) how does the browser handle the windowId >>>>>> b.) how does any servlet part detect the windodwId and how to detect that >>>>>> it is missing (and should be there) >>>>>> >>>>>> The windowId is added as root element to the view tree. I know that this >>>>>> did not work with the 'old' PrimeFaces proprietary ajax handling. But i &
Re: JSF - default ClientWindowRenderMode?
2014/1/10 Mark Struberg > Otherwise one could just open the same bookmark URL with the &windowId=123 > parameter in multiple browser tabs and you would again share the state > between them. Thats true but as far as i understand, we can't avoid such situations without streaming the windowhandler etc. Maybe you can explain LAZY a little bit more + some cases. 2014/1/10 Mark Struberg > > > It's a bit more complicated. > > In case of any mismatch (regardless if window.name is empty or just > different from the windowId url parameter) you need to trigger a more > complex handling to properly set the window.name. > > Otherwise one could just open the same bookmark URL with the &windowId=123 > parameter in multiple browser tabs and you would again share the state > between them. > > Actually the windowhandler.js script should contain all the necessary > handling code already. > > LieGrue, > strub > > > > > > > > > From: Thomas Andraschko > >To: dev@deltaspike.apache.org; Mark Struberg > >Sent: Friday, 10 January 2014, 13:58 > >Subject: Re: JSF - default ClientWindowRenderMode? > > > > > > > >Ok would be fine for me, too! > >The script for the LAZY mode will just do: > >- if window.name == undefined -> window.name == windowId > >- if window.name != undefined && window.name != windowId -> redirect > with removed windowId url param > > > > > > > > > > > > > >2014/1/10 Mark Struberg > > > > > >> > >>I'm fine with making the 'URL' mode the default. I still like the name > 'LAZY' better though ;) > >> > >>Even the CLIENT_WINDOW mode will add a windowId parameter to the URL in > some cases! > >>The name 'LAZY' just makes it more clear that the > wrong-browser-tab-detection is only done lazily and the initial request > might trash beans... > >> > >> > >> > >>LieGrue, > >>strub > >> > >> > >>> > >>> From: Thomas Andraschko > >>>To: dev@deltaspike.apache.org; Mark Struberg > >>>Sent: Friday, 10 January 2014, 13:43 > >> > >>>Subject: Re: JSF - default ClientWindowRenderMode? > >>> > >>> > >>>Ok! So keeping the new URL mode, which is indentical to the deafult CODI > >>>mode, makes sense for me. > >>> > >>>I will open another thread for the details here and some ideas about > >>>refactoring from my side. > >>> > >>>What do think about the default mode Mark? Should it be URL like its in > >>>CODI? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>2014/1/10 Mark Struberg > >>> > >>>> right. > >>>> > >>>> Basically you have to distinguish the two sides of the story. > >>>> > >>>> a.) how does the browser handle the windowId > >>>> b.) how does any servlet part detect the windodwId and how to detect > that > >>>> it is missing (and should be there) > >>>> > >>>> The windowId is added as root element to the view tree. I know that > this > >>>> did not work with the 'old' PrimeFaces proprietary ajax handling. But > i was > >>>> under the impression that this was long time fixed since then when > Cagatay > >>>> switched to standard jsf.js AJAX functions. Or is this still not > working? > >>>> > >>>> The point is that jsf.js always has to update the view root as it also > >>>> needs to update the view key, right? > >>>> > >>>> LieGrue, > >>>> strub > >>>> > >>>> > >>>> > >>>> > >>>> > > >>>> > From: Thomas Andraschko > >>>> >To: dev@deltaspike.apache.org; Mark Struberg > >>>> >Sent: Friday, 10 January 2014, 11:38 > >>>> >Subject: Re: JSF - default ClientWindowRenderMode? > >>>> > > >>>> > > >>>> > > >>>> >Addition to the windowhandler: > >>>> >It will also add windowId as hidden input for postback detection, > right? > >>>> >This will not work with e
Re: JSF - default ClientWindowRenderMode?
It's a bit more complicated. In case of any mismatch (regardless if window.name is empty or just different from the windowId url parameter) you need to trigger a more complex handling to properly set the window.name. Otherwise one could just open the same bookmark URL with the &windowId=123 parameter in multiple browser tabs and you would again share the state between them. Actually the windowhandler.js script should contain all the necessary handling code already. LieGrue, strub > > From: Thomas Andraschko >To: dev@deltaspike.apache.org; Mark Struberg >Sent: Friday, 10 January 2014, 13:58 >Subject: Re: JSF - default ClientWindowRenderMode? > > > >Ok would be fine for me, too! >The script for the LAZY mode will just do: >- if window.name == undefined -> window.name == windowId >- if window.name != undefined && window.name != windowId -> redirect with >removed windowId url param > > > > > > >2014/1/10 Mark Struberg > > >> >>I'm fine with making the 'URL' mode the default. I still like the name 'LAZY' >>better though ;) >> >>Even the CLIENT_WINDOW mode will add a windowId parameter to the URL in some >>cases! >>The name 'LAZY' just makes it more clear that the wrong-browser-tab-detection >>is only done lazily and the initial request might trash beans... >> >> >> >>LieGrue, >>strub >> >> >>> >>> From: Thomas Andraschko >>>To: dev@deltaspike.apache.org; Mark Struberg >>>Sent: Friday, 10 January 2014, 13:43 >> >>>Subject: Re: JSF - default ClientWindowRenderMode? >>> >>> >>>Ok! So keeping the new URL mode, which is indentical to the deafult CODI >>>mode, makes sense for me. >>> >>>I will open another thread for the details here and some ideas about >>>refactoring from my side. >>> >>>What do think about the default mode Mark? Should it be URL like its in >>>CODI? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>2014/1/10 Mark Struberg >>> >>>> right. >>>> >>>> Basically you have to distinguish the two sides of the story. >>>> >>>> a.) how does the browser handle the windowId >>>> b.) how does any servlet part detect the windodwId and how to detect that >>>> it is missing (and should be there) >>>> >>>> The windowId is added as root element to the view tree. I know that this >>>> did not work with the 'old' PrimeFaces proprietary ajax handling. But i was >>>> under the impression that this was long time fixed since then when Cagatay >>>> switched to standard jsf.js AJAX functions. Or is this still not working? >>>> >>>> The point is that jsf.js always has to update the view root as it also >>>> needs to update the view key, right? >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>> > >>>> > From: Thomas Andraschko >>>> >To: dev@deltaspike.apache.org; Mark Struberg >>>> >Sent: Friday, 10 January 2014, 11:38 >>>> >Subject: Re: JSF - default ClientWindowRenderMode? >>>> > >>>> > >>>> > >>>> >Addition to the windowhandler: >>>> >It will also add windowId as hidden input for postback detection, right? >>>> >This will not work with e.g. PrimeFaces' partial submit mode. >>>> >So the URL param will be used as fallback, right? >>>> > >>>> > >>>> > >>>> > >>>> >2014/1/10 Thomas Andraschko >>>> > >>>> >Hi Mark, >>>> >> >>>> >>i think the whole stuff needs a little bit more discussing. >>>> >> >>>> >> >>>> >>I would like now to list all window modes that we actually know: >>>> >> >>>> >> >>>> >>CODI >>>> >> >>>> >>- WIndowContextIdHolderComponent will automatically be added to the >>>> component tree for extracting the windowId in a postback >>>> >>- All 3 modes can use the WIndowContextIdHolderComponent as fallback for >>>> getting the windowId in a po
Re: JSF - default ClientWindowRenderMode?
Ok would be fine for me, too! The script for the LAZY mode will just do: - if window.name == undefined -> window.name == windowId - if window.name != undefined && window.name != windowId -> redirect with removed windowId url param 2014/1/10 Mark Struberg > > > I'm fine with making the 'URL' mode the default. I still like the name > 'LAZY' better though ;) > > Even the CLIENT_WINDOW mode will add a windowId parameter to the URL in > some cases! > The name 'LAZY' just makes it more clear that the > wrong-browser-tab-detection is only done lazily and the initial request > might trash beans... > > > LieGrue, > strub > > > > > > From: Thomas Andraschko > >To: dev@deltaspike.apache.org; Mark Struberg > >Sent: Friday, 10 January 2014, 13:43 > >Subject: Re: JSF - default ClientWindowRenderMode? > > > > > >Ok! So keeping the new URL mode, which is indentical to the deafult CODI > >mode, makes sense for me. > > > >I will open another thread for the details here and some ideas about > >refactoring from my side. > > > >What do think about the default mode Mark? Should it be URL like its in > >CODI? > > > > > > > > > > > > > > > > > > > > > >2014/1/10 Mark Struberg > > > >> right. > >> > >> Basically you have to distinguish the two sides of the story. > >> > >> a.) how does the browser handle the windowId > >> b.) how does any servlet part detect the windodwId and how to detect > that > >> it is missing (and should be there) > >> > >> The windowId is added as root element to the view tree. I know that this > >> did not work with the 'old' PrimeFaces proprietary ajax handling. But i > was > >> under the impression that this was long time fixed since then when > Cagatay > >> switched to standard jsf.js AJAX functions. Or is this still not > working? > >> > >> The point is that jsf.js always has to update the view root as it also > >> needs to update the view key, right? > >> > >> LieGrue, > >> strub > >> > >> > >> > >> > >> > > >> > From: Thomas Andraschko > >> >To: dev@deltaspike.apache.org; Mark Struberg > >> >Sent: Friday, 10 January 2014, 11:38 > >> >Subject: Re: JSF - default ClientWindowRenderMode? > >> > > >> > > >> > > >> >Addition to the windowhandler: > >> >It will also add windowId as hidden input for postback detection, > right? > >> >This will not work with e.g. PrimeFaces' partial submit mode. > >> >So the URL param will be used as fallback, right? > >> > > >> > > >> > > >> > > >> >2014/1/10 Thomas Andraschko > >> > > >> >Hi Mark, > >> >> > >> >>i think the whole stuff needs a little bit more discussing. > >> >> > >> >> > >> >>I would like now to list all window modes that we actually know: > >> >> > >> >> > >> >>CODI > >> >> > >> >>- WIndowContextIdHolderComponent will automatically be added to the > >> component tree for extracting the windowId in a postback > >> >>- All 3 modes can use the WIndowContextIdHolderComponent as fallback > for > >> getting the windowId in a postback > >> >> > >> >> > >> >>1) DefaultWindowHandler > >> >> > >> >> - Always appends the windowId to the URL and always gets the > windowId > >> from the URL > >> >> > >> >> - No JS checks etc. > >> >> > >> >> - opening a link in a new tab will not detect a new window / same > >> window will be reused > >> >> > >> >> > >> >> > >> >>2) ClientSideWindowHandler > >> >> > >> >> - Stream our windowhandler > >> >> > >> >> - windowhandler.html checks the window.name > >> >> > >> >> - if valid -> set cookie and redirect to the same page > >> >> > >> >> - if invalid -> remove windowId url param and redirect to the > >> same page > >> >> > >> >> - overwrites all c
Re: JSF - default ClientWindowRenderMode?
I'm fine with making the 'URL' mode the default. I still like the name 'LAZY' better though ;) Even the CLIENT_WINDOW mode will add a windowId parameter to the URL in some cases! The name 'LAZY' just makes it more clear that the wrong-browser-tab-detection is only done lazily and the initial request might trash beans... LieGrue, strub > > From: Thomas Andraschko >To: dev@deltaspike.apache.org; Mark Struberg >Sent: Friday, 10 January 2014, 13:43 >Subject: Re: JSF - default ClientWindowRenderMode? > > >Ok! So keeping the new URL mode, which is indentical to the deafult CODI >mode, makes sense for me. > >I will open another thread for the details here and some ideas about >refactoring from my side. > >What do think about the default mode Mark? Should it be URL like its in >CODI? > > > > > > > > > > >2014/1/10 Mark Struberg > >> right. >> >> Basically you have to distinguish the two sides of the story. >> >> a.) how does the browser handle the windowId >> b.) how does any servlet part detect the windodwId and how to detect that >> it is missing (and should be there) >> >> The windowId is added as root element to the view tree. I know that this >> did not work with the 'old' PrimeFaces proprietary ajax handling. But i was >> under the impression that this was long time fixed since then when Cagatay >> switched to standard jsf.js AJAX functions. Or is this still not working? >> >> The point is that jsf.js always has to update the view root as it also >> needs to update the view key, right? >> >> LieGrue, >> strub >> >> >> >> >> > >> > From: Thomas Andraschko >> >To: dev@deltaspike.apache.org; Mark Struberg >> >Sent: Friday, 10 January 2014, 11:38 >> >Subject: Re: JSF - default ClientWindowRenderMode? >> > >> > >> > >> >Addition to the windowhandler: >> >It will also add windowId as hidden input for postback detection, right? >> >This will not work with e.g. PrimeFaces' partial submit mode. >> >So the URL param will be used as fallback, right? >> > >> > >> > >> > >> >2014/1/10 Thomas Andraschko >> > >> >Hi Mark, >> >> >> >>i think the whole stuff needs a little bit more discussing. >> >> >> >> >> >>I would like now to list all window modes that we actually know: >> >> >> >> >> >>CODI >> >> >> >>- WIndowContextIdHolderComponent will automatically be added to the >> component tree for extracting the windowId in a postback >> >>- All 3 modes can use the WIndowContextIdHolderComponent as fallback for >> getting the windowId in a postback >> >> >> >> >> >>1) DefaultWindowHandler >> >> >> >> - Always appends the windowId to the URL and always gets the windowId >> from the URL >> >> >> >> - No JS checks etc. >> >> >> >> - opening a link in a new tab will not detect a new window / same >> window will be reused >> >> >> >> >> >> >> >>2) ClientSideWindowHandler >> >> >> >> - Stream our windowhandler >> >> >> >> - windowhandler.html checks the window.name >> >> >> >> - if valid -> set cookie and redirect to the same page >> >> >> >> - if invalid -> remove windowId url param and redirect to the >> same page >> >> >> >> - overwrites all click events to capturing a screenshot which >> will be displayed for further get requests? >> >> >> >> - Also appends the windowId to the URL? >> >> >> >> - The only mode which supports all edge cases >> >> >> >> >> >>3) ServerSideWindowHandler >> >> >> >> - Stored the windowId via flash-scope on redirect >> >> >> >> - Also appends the windowId to the URL? >> >> - opening a link in a new tab will not detect a new window / same >> window will be reused >> >> >> >> >> >> >> >> >> >> >> >> >> >>DeltaSpike: >> >> >> >> >> >>- WindowIdComponent must be added manually >> >> >> >> >
Re: JSF - default ClientWindowRenderMode?
Ok! So keeping the new URL mode, which is indentical to the deafult CODI mode, makes sense for me. I will open another thread for the details here and some ideas about refactoring from my side. What do think about the default mode Mark? Should it be URL like its in CODI? 2014/1/10 Mark Struberg > right. > > Basically you have to distinguish the two sides of the story. > > a.) how does the browser handle the windowId > b.) how does any servlet part detect the windodwId and how to detect that > it is missing (and should be there) > > The windowId is added as root element to the view tree. I know that this > did not work with the 'old' PrimeFaces proprietary ajax handling. But i was > under the impression that this was long time fixed since then when Cagatay > switched to standard jsf.js AJAX functions. Or is this still not working? > > The point is that jsf.js always has to update the view root as it also > needs to update the view key, right? > > LieGrue, > strub > > > > > > > > From: Thomas Andraschko > >To: dev@deltaspike.apache.org; Mark Struberg > >Sent: Friday, 10 January 2014, 11:38 > >Subject: Re: JSF - default ClientWindowRenderMode? > > > > > > > >Addition to the windowhandler: > >It will also add windowId as hidden input for postback detection, right? > >This will not work with e.g. PrimeFaces' partial submit mode. > >So the URL param will be used as fallback, right? > > > > > > > > > >2014/1/10 Thomas Andraschko > > > >Hi Mark, > >> > >>i think the whole stuff needs a little bit more discussing. > >> > >> > >>I would like now to list all window modes that we actually know: > >> > >> > >>CODI > >> > >>- WIndowContextIdHolderComponent will automatically be added to the > component tree for extracting the windowId in a postback > >>- All 3 modes can use the WIndowContextIdHolderComponent as fallback for > getting the windowId in a postback > >> > >> > >>1) DefaultWindowHandler > >> > >> - Always appends the windowId to the URL and always gets the windowId > from the URL > >> > >> - No JS checks etc. > >> > >> - opening a link in a new tab will not detect a new window / same > window will be reused > >> > >> > >> > >>2) ClientSideWindowHandler > >> > >> - Stream our windowhandler > >> > >> - windowhandler.html checks the window.name > >> > >> - if valid -> set cookie and redirect to the same page > >> > >> - if invalid -> remove windowId url param and redirect to the > same page > >> > >> - overwrites all click events to capturing a screenshot which > will be displayed for further get requests? > >> > >> - Also appends the windowId to the URL? > >> > >> - The only mode which supports all edge cases > >> > >> > >>3) ServerSideWindowHandler > >> > >> - Stored the windowId via flash-scope on redirect > >> > >> - Also appends the windowId to the URL? > >> - opening a link in a new tab will not detect a new window / same > window will be reused > >> > >> > >> > >> > >> > >> > >>DeltaSpike: > >> > >> > >>- WindowIdComponent must be added manually > >> > >> > >> > >>1) CLIENT_WINDOW: > >> - same as CODIs ClientSideWindowHandler > >> > >>2) LAZY > >> - new mix between DefaultWindowHandler and ClientSideWindowHandler? > >> > >> - renders the URL param but validates the windowID via > windowhandler.js, which will be loaded when the ds:windowId will be added > in the view > >> > >> > >> > >>3) URL (new) > >> > >> - same as CODIs DefaultWindowHandler > >> > >> > >>4) Delegated > >> > >> - take use of JSF 2.2 > >> > >> > >>Is this right? Please correct me! We can take this as base for the > documention later. > >> > >> > >>Regards, > >>Thomas > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>2014/1/1
Re: JSF - default ClientWindowRenderMode?
right. Basically you have to distinguish the two sides of the story. a.) how does the browser handle the windowId b.) how does any servlet part detect the windodwId and how to detect that it is missing (and should be there) The windowId is added as root element to the view tree. I know that this did not work with the 'old' PrimeFaces proprietary ajax handling. But i was under the impression that this was long time fixed since then when Cagatay switched to standard jsf.js AJAX functions. Or is this still not working? The point is that jsf.js always has to update the view root as it also needs to update the view key, right? LieGrue, strub > > From: Thomas Andraschko >To: dev@deltaspike.apache.org; Mark Struberg >Sent: Friday, 10 January 2014, 11:38 >Subject: Re: JSF - default ClientWindowRenderMode? > > > >Addition to the windowhandler: >It will also add windowId as hidden input for postback detection, right? >This will not work with e.g. PrimeFaces' partial submit mode. >So the URL param will be used as fallback, right? > > > > >2014/1/10 Thomas Andraschko > >Hi Mark, >> >>i think the whole stuff needs a little bit more discussing. >> >> >>I would like now to list all window modes that we actually know: >> >> >>CODI >> >>- WIndowContextIdHolderComponent will automatically be added to the component >>tree for extracting the windowId in a postback >>- All 3 modes can use the WIndowContextIdHolderComponent as fallback for >>getting the windowId in a postback >> >> >>1) DefaultWindowHandler >> >> - Always appends the windowId to the URL and always gets the windowId from >>the URL >> >> - No JS checks etc. >> >> - opening a link in a new tab will not detect a new window / same window >>will be reused >> >> >> >>2) ClientSideWindowHandler >> >> - Stream our windowhandler >> >> - windowhandler.html checks the window.name >> >> - if valid -> set cookie and redirect to the same page >> >> - if invalid -> remove windowId url param and redirect to the same page >> >> - overwrites all click events to capturing a screenshot which will be >>displayed for further get requests? >> >> - Also appends the windowId to the URL? >> >> - The only mode which supports all edge cases >> >> >>3) ServerSideWindowHandler >> >> - Stored the windowId via flash-scope on redirect >> >> - Also appends the windowId to the URL? >> - opening a link in a new tab will not detect a new window / same window >>will be reused >> >> >> >> >> >> >>DeltaSpike: >> >> >>- WindowIdComponent must be added manually >> >> >> >>1) CLIENT_WINDOW: >> - same as CODIs ClientSideWindowHandler >> >>2) LAZY >> - new mix between DefaultWindowHandler and ClientSideWindowHandler? >> >> - renders the URL param but validates the windowID via windowhandler.js, >>which will be loaded when the ds:windowId will be added in the view >> >> >> >>3) URL (new) >> >> - same as CODIs DefaultWindowHandler >> >> >>4) Delegated >> >> - take use of JSF 2.2 >> >> >>Is this right? Please correct me! We can take this as base for the >>documention later. >> >> >>Regards, >>Thomas >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>2014/1/10 Mark Struberg >> >> >>> >>>Hi Thomas! >>> >>>Well, it's just a different name ;) >>> >>>The default handling in CODI is lazy windowId dropping if you do not use the >>>ClientSideWindowHandler. >>>Means a request runs through to the target bean and renders the page. And >>>the windowId only gets checked/reset when the page gets loaded by the >>>browser and the javascript _lazily_ detects that we are on the wrong browser >>>tab (windowId != window.name). >>> >>> >>>Transporting the windowId via URL is only a small necessity actually ;) >>> >>> should already contain all the JavaScript needed for the lazy >>>dropping. >>> >>> >>>LieGrue, >>>strub >>> >>> >>> >>> >>> >>>> >
Re: JSF - default ClientWindowRenderMode?
Addition to DeltaSpike: The windowIdComponent will be just used to render via JS the current valid windowId. 2014/1/10 Thomas Andraschko > Addition to the windowhandler: > It will also add windowId as hidden input for postback detection, right? > This will not work with e.g. PrimeFaces' partial submit mode. > So the URL param will be used as fallback, right? > > > 2014/1/10 Thomas Andraschko > >> Hi Mark, >> >> i think the whole stuff needs a little bit more discussing. >> >> I would like now to list all window modes that we actually know: >> >> CODI >> >> - WIndowContextIdHolderComponent will automatically be added to the >> component tree for extracting the windowId in a postback >> - All 3 modes can use the WIndowContextIdHolderComponent as fallback for >> getting the windowId in a postback >> >> 1) DefaultWindowHandler >>- Always appends the windowId to the URL and always gets the windowId >> from the URL >>- No JS checks etc. >>- opening a link in a new tab will not detect a new window / same >> window will be reused >> >> 2) ClientSideWindowHandler >>- Stream our windowhandler >>- windowhandler.html checks the window.name >>- if valid -> set cookie and redirect to the same page >>- if invalid -> remove windowId url param and redirect to the same >> page >>- overwrites all click events to capturing a screenshot which will >> be displayed for further get requests? >>- Also appends the windowId to the URL? >>- The only mode which supports all edge cases >> >> 3) ServerSideWindowHandler >>- Stored the windowId via flash-scope on redirect >>- Also appends the windowId to the URL? >>- opening a link in a new tab will not detect a new window / same >> window will be reused >> >> >> >> DeltaSpike: >> >> - WindowIdComponent must be added manually >> >> 1) CLIENT_WINDOW: >>- same as CODIs ClientSideWindowHandler >> 2) LAZY >>- new mix between DefaultWindowHandler and ClientSideWindowHandler? >>- renders the URL param but validates the windowID via >> windowhandler.js, which will be loaded when the ds:windowId will be added >> in the view >> >> 3) URL (new) >>- same as CODIs DefaultWindowHandler >> >> 4) Delegated >>- take use of JSF 2.2 >> >> Is this right? Please correct me! We can take this as base for the >> documention later. >> >> Regards, >> Thomas >> >> >> >> >> >> >> >> >> >> >> 2014/1/10 Mark Struberg >> >>> >>> >>> Hi Thomas! >>> >>> Well, it's just a different name ;) >>> >>> The default handling in CODI is lazy windowId dropping if you do not use >>> the ClientSideWindowHandler. >>> Means a request runs through to the target bean and renders the page. >>> And the windowId only gets checked/reset when the page gets loaded by the >>> browser and the javascript _lazily_ detects that we are on the wrong >>> browser tab (windowId != window.name). >>> >>> >>> Transporting the windowId via URL is only a small necessity actually ;) >>> >>> should already contain all the JavaScript needed for the >>> lazy dropping. >>> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> >>> > >>> > From: Thomas Andraschko >>> >To: dev@deltaspike.apache.org; Mark Struberg >>> >Sent: Friday, 10 January 2014, 10:50 >>> >Subject: Re: JSF - default ClientWindowRenderMode? >>> > >>> > >>> > >>> >As LAZY is currently not used, no documentation available and the >>> javadoc said something about "javascript handling on client side", i >>> thought it will a different kind of handling in the future. >>> >What should be difference between URL rendering mode and LAZY? >>> > >>> > >>> > >>> > >>> > >>> > >>> >2014/1/10 Mark Struberg >>> > >>> >The URL rendering mode of CODI is what I intended with LAZY. >>> >> >>> >> >>> >>LieGrue, >>> >>strub >>> >> >>> >> >>> >> >>> >> >>> >>> >>> >>> From: Gerhard Petracek >>> >>>To: dev@deltaspike.apache.org >>> >>>Sent: Friday, 10 January 2014, 9:33 >>> >>>Subject: Re: JSF - default ClientWindowRenderMode? >>> >> >>> >>> >>> >>> >>> >>>+1 >>> >>> >>> >>>regards, >>> >>>gerhard >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>2014/1/9 Thomas Andraschko >>> >>> >>> >>>> Hi, >>> >>>> >>> >>>> currently the default rendering mode is our windowhandler js/html >>> way. >>> >>>> Many people don't like it because you always get a loading screen >>> for EACH >>> >>>> GET request: >>> >>>> >>> >>>> >>> >>>> >>> http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike >>> >>>> https://issues.apache.org/jira/browse/DELTASPIKE-454 >>> >>>> >>> >>>> i readded a URL rendering mode in DS like it was in CODI. >>> >>>> I know that it doesn't cover all cases but it's likely enough for >>> the most >>> >>>> users. >>> >>>> >>> >>>> What do you think about making the URL mode as default like it was >>> in CODI >>> >>>> before? >>> >>>> >>> >>>> Regards, >>> >>>> Thomas >>> >>>> >>> >>> >>> >>> >>> >>> >>> > >>> > >>> > >>> >> >> >
Re: JSF - default ClientWindowRenderMode?
Addition to the windowhandler: It will also add windowId as hidden input for postback detection, right? This will not work with e.g. PrimeFaces' partial submit mode. So the URL param will be used as fallback, right? 2014/1/10 Thomas Andraschko > Hi Mark, > > i think the whole stuff needs a little bit more discussing. > > I would like now to list all window modes that we actually know: > > CODI > > - WIndowContextIdHolderComponent will automatically be added to the > component tree for extracting the windowId in a postback > - All 3 modes can use the WIndowContextIdHolderComponent as fallback for > getting the windowId in a postback > > 1) DefaultWindowHandler >- Always appends the windowId to the URL and always gets the windowId > from the URL >- No JS checks etc. >- opening a link in a new tab will not detect a new window / same > window will be reused > > 2) ClientSideWindowHandler >- Stream our windowhandler >- windowhandler.html checks the window.name >- if valid -> set cookie and redirect to the same page >- if invalid -> remove windowId url param and redirect to the same > page >- overwrites all click events to capturing a screenshot which will > be displayed for further get requests? >- Also appends the windowId to the URL? >- The only mode which supports all edge cases > > 3) ServerSideWindowHandler >- Stored the windowId via flash-scope on redirect >- Also appends the windowId to the URL? >- opening a link in a new tab will not detect a new window / same > window will be reused > > > > DeltaSpike: > > - WindowIdComponent must be added manually > > 1) CLIENT_WINDOW: >- same as CODIs ClientSideWindowHandler > 2) LAZY >- new mix between DefaultWindowHandler and ClientSideWindowHandler? >- renders the URL param but validates the windowID via > windowhandler.js, which will be loaded when the ds:windowId will be added > in the view > > 3) URL (new) >- same as CODIs DefaultWindowHandler > > 4) Delegated >- take use of JSF 2.2 > > Is this right? Please correct me! We can take this as base for the > documention later. > > Regards, > Thomas > > > > > > > > > > > 2014/1/10 Mark Struberg > >> >> >> Hi Thomas! >> >> Well, it's just a different name ;) >> >> The default handling in CODI is lazy windowId dropping if you do not use >> the ClientSideWindowHandler. >> Means a request runs through to the target bean and renders the page. And >> the windowId only gets checked/reset when the page gets loaded by the >> browser and the javascript _lazily_ detects that we are on the wrong >> browser tab (windowId != window.name). >> >> >> Transporting the windowId via URL is only a small necessity actually ;) >> >> should already contain all the JavaScript needed for the >> lazy dropping. >> >> >> LieGrue, >> strub >> >> >> >> >> >> > >> > From: Thomas Andraschko >> >To: dev@deltaspike.apache.org; Mark Struberg >> >Sent: Friday, 10 January 2014, 10:50 >> >Subject: Re: JSF - default ClientWindowRenderMode? >> > >> > >> > >> >As LAZY is currently not used, no documentation available and the >> javadoc said something about "javascript handling on client side", i >> thought it will a different kind of handling in the future. >> >What should be difference between URL rendering mode and LAZY? >> > >> > >> > >> > >> > >> > >> >2014/1/10 Mark Struberg >> > >> >The URL rendering mode of CODI is what I intended with LAZY. >> >> >> >> >> >>LieGrue, >> >>strub >> >> >> >> >> >> >> >> >> >>> >> >>> From: Gerhard Petracek >> >>>To: dev@deltaspike.apache.org >> >>>Sent: Friday, 10 January 2014, 9:33 >> >>>Subject: Re: JSF - default ClientWindowRenderMode? >> >> >> >>> >> >>> >> >>>+1 >> >>> >> >>>regards, >> >>>gerhard >> >>> >> >>> >> >>> >> >>> >> >>>2014/1/9 Thomas Andraschko >> >>> >> >>>> Hi, >> >>>> >> >>>> currently the default rendering mode is our windowhandler js/html >> way. >> >>>> Many people don't like it because you always get a loading screen >> for EACH >> >>>> GET request: >> >>>> >> >>>> >> >>>> >> http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike >> >>>> https://issues.apache.org/jira/browse/DELTASPIKE-454 >> >>>> >> >>>> i readded a URL rendering mode in DS like it was in CODI. >> >>>> I know that it doesn't cover all cases but it's likely enough for >> the most >> >>>> users. >> >>>> >> >>>> What do you think about making the URL mode as default like it was >> in CODI >> >>>> before? >> >>>> >> >>>> Regards, >> >>>> Thomas >> >>>> >> >>> >> >>> >> >>> >> > >> > >> > >> > >
Re: JSF - default ClientWindowRenderMode?
Hi Mark, i think the whole stuff needs a little bit more discussing. I would like now to list all window modes that we actually know: CODI - WIndowContextIdHolderComponent will automatically be added to the component tree for extracting the windowId in a postback - All 3 modes can use the WIndowContextIdHolderComponent as fallback for getting the windowId in a postback 1) DefaultWindowHandler - Always appends the windowId to the URL and always gets the windowId from the URL - No JS checks etc. - opening a link in a new tab will not detect a new window / same window will be reused 2) ClientSideWindowHandler - Stream our windowhandler - windowhandler.html checks the window.name - if valid -> set cookie and redirect to the same page - if invalid -> remove windowId url param and redirect to the same page - overwrites all click events to capturing a screenshot which will be displayed for further get requests? - Also appends the windowId to the URL? - The only mode which supports all edge cases 3) ServerSideWindowHandler - Stored the windowId via flash-scope on redirect - Also appends the windowId to the URL? - opening a link in a new tab will not detect a new window / same window will be reused DeltaSpike: - WindowIdComponent must be added manually 1) CLIENT_WINDOW: - same as CODIs ClientSideWindowHandler 2) LAZY - new mix between DefaultWindowHandler and ClientSideWindowHandler? - renders the URL param but validates the windowID via windowhandler.js, which will be loaded when the ds:windowId will be added in the view 3) URL (new) - same as CODIs DefaultWindowHandler 4) Delegated - take use of JSF 2.2 Is this right? Please correct me! We can take this as base for the documention later. Regards, Thomas 2014/1/10 Mark Struberg > > > Hi Thomas! > > Well, it's just a different name ;) > > The default handling in CODI is lazy windowId dropping if you do not use > the ClientSideWindowHandler. > Means a request runs through to the target bean and renders the page. And > the windowId only gets checked/reset when the page gets loaded by the > browser and the javascript _lazily_ detects that we are on the wrong > browser tab (windowId != window.name). > > > Transporting the windowId via URL is only a small necessity actually ;) > > should already contain all the JavaScript needed for the > lazy dropping. > > > LieGrue, > strub > > > > > > > > > From: Thomas Andraschko > >To: dev@deltaspike.apache.org; Mark Struberg > >Sent: Friday, 10 January 2014, 10:50 > >Subject: Re: JSF - default ClientWindowRenderMode? > > > > > > > >As LAZY is currently not used, no documentation available and the javadoc > said something about "javascript handling on client side", i thought it > will a different kind of handling in the future. > >What should be difference between URL rendering mode and LAZY? > > > > > > > > > > > > > >2014/1/10 Mark Struberg > > > >The URL rendering mode of CODI is what I intended with LAZY. > >> > >> > >>LieGrue, > >>strub > >> > >> > >> > >> > >>> > >>> From: Gerhard Petracek > >>>To: dev@deltaspike.apache.org > >>>Sent: Friday, 10 January 2014, 9:33 > >>>Subject: Re: JSF - default ClientWindowRenderMode? > >> > >>> > >>> > >>>+1 > >>> > >>>regards, > >>>gerhard > >>> > >>> > >>> > >>> > >>>2014/1/9 Thomas Andraschko > >>> > >>>> Hi, > >>>> > >>>> currently the default rendering mode is our windowhandler js/html way. > >>>> Many people don't like it because you always get a loading screen for > EACH > >>>> GET request: > >>>> > >>>> > >>>> > http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike > >>>> https://issues.apache.org/jira/browse/DELTASPIKE-454 > >>>> > >>>> i readded a URL rendering mode in DS like it was in CODI. > >>>> I know that it doesn't cover all cases but it's likely enough for the > most > >>>> users. > >>>> > >>>> What do you think about making the URL mode as default like it was in > CODI > >>>> before? > >>>> > >>>> Regards, > >>>> Thomas > >>>> > >>> > >>> > >>> > > > > > > >
Re: JSF - default ClientWindowRenderMode?
Hi Thomas! Well, it's just a different name ;) The default handling in CODI is lazy windowId dropping if you do not use the ClientSideWindowHandler. Means a request runs through to the target bean and renders the page. And the windowId only gets checked/reset when the page gets loaded by the browser and the javascript _lazily_ detects that we are on the wrong browser tab (windowId != window.name). Transporting the windowId via URL is only a small necessity actually ;) should already contain all the JavaScript needed for the lazy dropping. LieGrue, strub > > From: Thomas Andraschko >To: dev@deltaspike.apache.org; Mark Struberg >Sent: Friday, 10 January 2014, 10:50 >Subject: Re: JSF - default ClientWindowRenderMode? > > > >As LAZY is currently not used, no documentation available and the javadoc said >something about "javascript handling on client side", i thought it will a >different kind of handling in the future. >What should be difference between URL rendering mode and LAZY? > > > > > > >2014/1/10 Mark Struberg > >The URL rendering mode of CODI is what I intended with LAZY. >> >> >>LieGrue, >>strub >> >> >> >> >>>________________ >>> From: Gerhard Petracek >>>To: dev@deltaspike.apache.org >>>Sent: Friday, 10 January 2014, 9:33 >>>Subject: Re: JSF - default ClientWindowRenderMode? >> >>> >>> >>>+1 >>> >>>regards, >>>gerhard >>> >>> >>> >>> >>>2014/1/9 Thomas Andraschko >>> >>>> Hi, >>>> >>>> currently the default rendering mode is our windowhandler js/html way. >>>> Many people don't like it because you always get a loading screen for EACH >>>> GET request: >>>> >>>> >>>> http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike >>>> https://issues.apache.org/jira/browse/DELTASPIKE-454 >>>> >>>> i readded a URL rendering mode in DS like it was in CODI. >>>> I know that it doesn't cover all cases but it's likely enough for the most >>>> users. >>>> >>>> What do you think about making the URL mode as default like it was in CODI >>>> before? >>>> >>>> Regards, >>>> Thomas >>>> >>> >>> >>> > > >
Re: JSF - default ClientWindowRenderMode?
As LAZY is currently not used, no documentation available and the javadoc said something about "javascript handling on client side", i thought it will a different kind of handling in the future. What should be difference between URL rendering mode and LAZY? 2014/1/10 Mark Struberg > The URL rendering mode of CODI is what I intended with LAZY. > > > LieGrue, > strub > > > > > > > > From: Gerhard Petracek > >To: dev@deltaspike.apache.org > >Sent: Friday, 10 January 2014, 9:33 > >Subject: Re: JSF - default ClientWindowRenderMode? > > > > > >+1 > > > >regards, > >gerhard > > > > > > > > > >2014/1/9 Thomas Andraschko > > > >> Hi, > >> > >> currently the default rendering mode is our windowhandler js/html way. > >> Many people don't like it because you always get a loading screen for > EACH > >> GET request: > >> > >> > >> > http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike > >> https://issues.apache.org/jira/browse/DELTASPIKE-454 > >> > >> i readded a URL rendering mode in DS like it was in CODI. > >> I know that it doesn't cover all cases but it's likely enough for the > most > >> users. > >> > >> What do you think about making the URL mode as default like it was in > CODI > >> before? > >> > >> Regards, > >> Thomas > >> > > > > > > >
Re: JSF - default ClientWindowRenderMode?
The URL rendering mode of CODI is what I intended with LAZY. LieGrue, strub > > From: Gerhard Petracek >To: dev@deltaspike.apache.org >Sent: Friday, 10 January 2014, 9:33 >Subject: Re: JSF - default ClientWindowRenderMode? > > >+1 > >regards, >gerhard > > > > >2014/1/9 Thomas Andraschko > >> Hi, >> >> currently the default rendering mode is our windowhandler js/html way. >> Many people don't like it because you always get a loading screen for EACH >> GET request: >> >> >> http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike >> https://issues.apache.org/jira/browse/DELTASPIKE-454 >> >> i readded a URL rendering mode in DS like it was in CODI. >> I know that it doesn't cover all cases but it's likely enough for the most >> users. >> >> What do you think about making the URL mode as default like it was in CODI >> before? >> >> Regards, >> Thomas >> > > >
Re: JSF - default ClientWindowRenderMode?
+1 regards, gerhard 2014/1/9 Thomas Andraschko > Hi, > > currently the default rendering mode is our windowhandler js/html way. > Many people don't like it because you always get a loading screen for EACH > GET request: > > > http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike > https://issues.apache.org/jira/browse/DELTASPIKE-454 > > i readded a URL rendering mode in DS like it was in CODI. > I know that it doesn't cover all cases but it's likely enough for the most > users. > > What do you think about making the URL mode as default like it was in CODI > before? > > Regards, > Thomas >
Re: JSF - default ClientWindowRenderMode?
If I ever were to post a meme to this mail list it would probably be: "If my application could have just one of dsRid and windowId and no loading splash I would be so happy" cheers On 9 January 2014 22:52, Thomas Andraschko wrote: > Hi, > > currently the default rendering mode is our windowhandler js/html way. > Many people don't like it because you always get a loading screen for EACH > GET request: > > > http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike > https://issues.apache.org/jira/browse/DELTASPIKE-454 > > i readded a URL rendering mode in DS like it was in CODI. > I know that it doesn't cover all cases but it's likely enough for the most > users. > > What do you think about making the URL mode as default like it was in CODI > before? > > Regards, > Thomas >
