Ok, small addition: We must stream the windowhandler for Post / Redirect / Get in non-ajax requests, as the form could have target attribute to open the it in a new browser tab.
2015-11-18 10:15 GMT+01:00 Thomas Andraschko <[email protected]>: > Hi, > > yep, as i said, the GET link is working fine as the windowhandler isn't > streamed there. > > In the other cases, we correctly store and restore the html tree. So i'm > not sure we can do anything to avoid the short flickering. > > However, we probably have a solution to avoid the streaming also between > Post/Redirect/Get. > We could overwrite the redirect handling and append the request token to > the url, to mark the next Get request as valid. > So every action on the clientwindow test page, should work without any > flickering. > > Cases with windowhandler streaming: > - GET requests > - open a URL > - click on a link when isClientWindowTokenizedRedirectEnabled is > deactivated > - h/p:button with defined href (or just window.location.href js calls) > - Open a link in new tab > > Cases without windowhandler streaming: > - Post requests (ajax and non ajax) > - Post / Redirect / Get (ajax and non ajax) > - Get request + redirect e.g. in f:viewAction > - click on a link when isClientWindowTokenizedRedirectEnabled is activated > > Do i miss any case? > > If the list above is complete, we could also cleanup our options a little > bit: > - isClientWindowStoreWindowTreeEnabledOnAjaxRequest > This was actually a workaround for the Post/Redirect/Get > - isClientWindowTokenizedRedirectEnabled > I would activate it per default - this handling shoudln't break anything > and reduces the streaming alot > - Maybe! html tree store/restoring > The only case left which would benefit from it is the h:button/p:button > with href case. > Not sure if we should maintain such a BIG feature for only one very > small case. > > > WDYT? > > > 2015-11-17 21:38 GMT+01:00 Markus Lachat <[email protected]>: > >> Hi, >> >> here is a link to a very quick and basic example I did (with an ugly >> background color to better spot the loading) >> >> http://dsplayground-mlachat.rhcloud.com/views/windowhandling/clientwindow/test.xhtml >> >> I must admit I have copied that from DS repo and published the demo to >> the cloud. I added a primefaces menu like this: >> <p:menu> >> <p:menuitem value="Navigate to test1" >> action="#{myNavigationController.redirect('org.apache.deltaspike.playground.windowhandling.Pages$Test')}"/> >> <p:menuitem value="Navigate to test2" >> action="#{myNavigationController.redirect('org.apache.deltaspike.playground.windowhandling.Pages$Test2')}"/> >> </p:menu> >> >> Best regards, >> Markus >> >> -----Ursprüngliche Nachricht----- >> Von: Thomas Andraschko [mailto:[email protected]] >> Gesendet: Dienstag, 17. November 2015 17:57 >> An: [email protected] >> Betreff: Re: 2 issues with CIENTWINDOW mode >> >> Hi, >> >> 1) please provide a example. >> If there isn't something wrong with your example, we probably can't >> remove the flickering completely. It would depend on the browser than. >> Also, when you activated isClientWindowTokenizedRedirectEnabled, we >> should not even stream the html when you click on a simple GET link. >> >> Regards, >> THomas >> >> >> 2015-11-17 17:51 GMT+01:00 Markus Lachat <[email protected]>: >> >> > Hi Thomas, >> > >> > 1) It would occur also on a link defined like this. <h:link value="GET >> > Link" outcome="test.xhtml" /> where test is the current site. I >> > changed the background of this test site to better spot this behavior. >> > Empty sites are quite fast, esp. on localhost. Once you do it remote >> > with some DB load and a possibly slow server, it also becomes very >> flashy. >> > >> > 2) I just created >> > https://issues.apache.org/jira/browse/DELTASPIKE-1023 >> > Thanks for considering it. >> > >> > Let me know if you need the demo for 1) >> > >> > Best regards, >> > Markus >> > >> > -----Ursprüngliche Nachricht----- >> > Von: Thomas Andraschko [mailto:[email protected]] >> > Gesendet: Dienstag, 17. November 2015 17:34 >> > An: [email protected] >> > Betreff: Re: 2 issues with CIENTWINDOW mode >> > >> > Hi Markus, >> > >> > 1) does it still flicker for you when you use a button or normal link? >> > Is it just related to the PF menu? Or PrimeFaces ajax request? >> > >> > 2) Could be possible - not sure. >> > please create a feature request. >> > >> > Regards, >> > Thomas >> > >> > 2015-11-17 17:26 GMT+01:00 Markus Lachat <[email protected]>: >> > >> > > Hi, >> > > >> > > The first issue is about the flickering of the screen: >> > > I am wondering if I configured anything wrong. I implemented the >> > > specialized ClientWindowConfig and override these 4 methods and each >> > > returns true >> > > >> > > isClientWindowStoreWindowTreeEnabledOnLinkClick >> > > isClientWindowStoreWindowTreeEnabledOnAjaxRequest >> > > isClientWindowStoreWindowTreeEnabledOnButtonClick >> > > isClientWindowTokenizedRedirectEnabled >> > > >> > > All working, no destroyed viewAccessScope and so on, however I still >> > > see a lot of flickering when navigating over a primefaces menu >> > > backed by a navigation bean (responsible for the typesafe outcome). >> > > These are mainly links that cause a POST with an outcome or just >> > > simple GET links. I could provide a demo for this issue. >> > > >> > > >> > > The second issue is a nice to have for better user experience: >> > > It works for buttons (thank you Thomas for fixing this >> > > https://issues.apache.org/jira/browse/DELTASPIKE-968) >> > > But when the user scrolled down, somewhere at the bottom of a long >> > > page to click the buttons the page seems to scroll up again, because >> > > it shows the state of the html when the page was initially loaded. >> > > >> > > Can you somehow improve that behavior to show the state of the >> > > browser just the moment before a link or button is clicked? >> > > >> > > Best regards, >> > > Markus >> > > >> > > >> > >> > >> >> >
