Hi Thomas, I assume you ask for opinions from other users on this mailing list, because I personally can't really help you with these questions.
I can offer to run tests on any provided snapshot build or even build it myself from a feature branch. Just in case you need feedback how your prospective solutions works out on our real world application before releasing it to the wild. -----Ursprüngliche Nachricht----- Von: Thomas Andraschko [mailto:[email protected]] Gesendet: Mittwoch, 18. November 2015 11:31 An: [email protected] Betreff: Re: 2 issues with CIENTWINDOW mode 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/clientwi >> ndow/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.play >> ground.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 >> > > >> > > >> > >> > >> >> >
