> 1. To implement 2. it is necessary > a "requestId". MyFaces FlashImpl uses a counter and store its value inside > a cookie
The trick could be the same which I do atm for the 2nd windowId request: Each URL always contains the windowId, and the cookie name also contains the windowId. This way 2 tabs cannot get the same cookie... LieGrue, strub ----- Original Message ----- > From: Leonardo Uribe <[email protected]> > To: MyFaces Development <[email protected]>; Mark Struberg > <[email protected]> > Cc: > Sent: Friday, November 18, 2011 11:08 PM > Subject: Re: [core extcdi] is required to create another proposal about > windowId? > > Hi > > MS>> The ClientSideWindowHandler solution in CODI looks good so far, but > there > MS>> is still a lot to do. > > MS>> And like every technology, it has it's pros and cons... > > MS>> What do you think about making the windowId provider pluggable in > MyFaces > MS>> core first? > > I have been thinking about every possible option we have for implement this > and > the conclusion was the best way is make something like the hack done in CODI > or > a "variant" of it, like the one described on: > > http://wiki.apache.org/myfaces/Drafts/WindowId > > (Mixed approach of the first prototype) > > From the point of view of MyFaces Core, any solution should be bound to the > renderkit in some way. So, windowId concept has sense to include it on the > spec > but its implementation should be done according to the renderkit. If the > renderkit handles html, do the hack proposed but if is xml, do other thing > and so on. It sounds like something to do outside MyFaces Core. Basically the > problem is how to create an interface about something that could require > changes over the renderkit/viewhandler?. > > Maybe we can minimize the problem, and provide an interface like this: > > public interface WindowIdRenderKitAware > { > public String getCurrentWindowId(FacesContext facesContext); > } > > But let the details about how to "plug" all pieces inside CODI. > MyFaces Core > just offer the "integration point", and the default algorithm just do > what is > doing right now. Who should implement this interface? the renderkit, even if > in the implementation the value can be stored inside FacesContext attribute > map or request map. There exists a RenderKitWrapper interface, so it is > easy to create a wrapper for default HTML_BASIC renderkit or any other and > then scan through the wrappers and the first one implementing the interface > will be the choosen. > > MS>> The REAL problem with JSF and multiple tabs is that once you open 2 > tabs > MS>> and click in 1 of them often enough, then you will destroy the state > of > MS>> the view in the other tab as well somewhen. Usually after 20 requests > MS>> (default). > > There are two points where this logic could be useful inside MyFaces Core : > > 1. Server side state > 2. Flash scope > > But in practice the only really relevant is 1. To implement 2. it is necessary > a "requestId". MyFaces FlashImpl uses a counter and store its value > inside > a cookie. To fix this scope properly, the best is create a ExternalContext > wrapper and provide and alternate Flash object, but that sounds like something > that can be done outside MyFaces Core. If you are using CDI scopes, it sounds > reasonable to provide an alternate Flash scope in CODI. > > If we can just modify the logic inside server side state to include > "windowId" > concept, it will be enough. > > MS>> To come over this, we need to store the n last views not only per > session, > MS>> but also per browser tab (==windowId). > MS>> Of course, there can be lots of fancy stuff done to detect closed > tabs, > MS>> etc. But all this is much more stable if we really have the > opportunity > MS>> to distinguish between tabs. We can e.g. also introduce a > configuration > MS>> for maximum allowed tabs, to reduce memory blasting. > > Really since all state is stored in session, if the session is invalidated all > tabs are removed from memory. Basically we already have params for max number > of sessions and max number of logical sessions (which in fact can be seen > as "tabs"). So what we have right now is ok, we just need to include > windowId > concept into the logic and that's it. > > MS>> All this is actually completely independent of how the windowId > get's > MS>> created and checked imo. > > Yes, that's right. > > MS>> I now tend to do the following (just atm creating a better playground > MS>> example in CODI + hack on the ClientSideWindowHandler): > MS>> > MS>> a.) the cookie thingy is pretty bääh. it just doesn't work if a > user clicks > MS>> quickly through a list and opens lots of 'detail pages' on > different tabs > MS>> within 2 seconds. > MS>> > MS>> b.) it's currently a 'one or the other' thingy, and I now > thought about > MS>> combining the lazyWindowIdDropp.js and the current windowhandler.js > MS>> > MS>> My current research goes into the direction of > MS>> > MS>> 1.) always adding the windowId to each and every link and transport > the > MS>> windowId only via this parameter. > MS>> > MS>> 2.) For HTML5-browsers (detected via UserAgent) I render the > MS>> windowhandler.html intermediate page which does all the fancy stuff > of > MS>> dynamically applying the old DOM on the intermediate page, etc. For > other > MS>> clients we rely on the lazyWindowId script. > > Ok, sounds promising. So, I'll focus on how to fix the logic for myfaces > core server side state saving > (org.apache.myfaces.renderkit.ServerSideStateCacheImpl), with the alternative > proposed in this mail (WindowIdRenderKitAware interface, and then use a > RenderKit wrapper). > > regards, > > Leonardo Uribe > > 2011/11/18 Mark Struberg <[email protected]>: >> I now tend to do the following (just atm creating a better playground > example in CODI + hack on the ClientSideWindowHandler): >> >> a.) the cookie thingy is pretty bääh. it just doesn't work if a user > clicks quickly through a list and opens lots of 'detail pages' on > different tabs within 2 seconds. >> >> b.) it's currently a 'one or the other' thingy, and I now > thought about combining the lazyWindowIdDropp.js and the current > windowhandler.js >> >> My current research goes into the direction of >> >> 1.) always adding the windowId to each and every link and transport the > windowId only via this parameter. >> >> 2.) For HTML5-browsers (detected via UserAgent) I render the > windowhandler.html intermediate page which does all the fancy stuff of > dynamically applying the old DOM on the intermediate page, etc. For other > clients we rely on the lazyWindowId script. >> >> Any help is welcome. >> >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >>> From: Jakob Korherr <[email protected]> >>> To: MyFaces Development <[email protected]>; Mark Struberg > <[email protected]> >>> Cc: >>> Sent: Friday, November 18, 2011 2:23 PM >>> Subject: Re: [core extcdi] is required to create another proposal about > windowId? >>> >>> Hi, >>> >>>> PS: btw, a PhD student in my institute made me aware of a trick > with the >>> browser history. I think Jakob also already researched in this > direction: >>>> > https://github.com/balupton/history.js/wiki/Intelligent-State-Handling >>>> This mechanism does only 1 GET request (mine does 2), but with > pure AJAX >>> you imo cannot fully replace the header once the window is fully > loaded. Thus >>> you cannot easily handle dynamically loaded CSS, background images, etc > with >>> this approach. >>> >>> Yeap, I did some research in this area and also came across >>> https://github.com/balupton/history.js (there are actually a hand full >>> of projects on github which accomplish the same thing). This sure is a >>> very good way of implementing a rich web 2.0 application with working >>> history (--> back button), facebook and twitter are surely the most >>> famous examples of this technique. >>> >>> However, Mark is right: doing this, you will end up in a lot of >>> browser related problems when it comes to dynamic loading of >>> stylesheets, scripts, etc.. Facebook and twitter managed to get this >>> working for their purposes, but IMO it is not that easy for a standard >>> JSF developer/architect. >>> >>> Regards, >>> Jakob >>> >>> 2011/11/18 Mark Struberg <[email protected]>: >>>> Hi! >>>> >>>> The ClientSideWindowHandler solution in CODI looks good so far, > but there >>> is still a lot to do. >>>> >>>> And like every technology, it has it's pros and cons... >>>> >>>> What do you think about making the windowId provider pluggable in > MyFaces >>> core first? >>>> >>>> The REAL problem with JSF and multiple tabs is that once you open > 2 tabs >>> and click in 1 of them often enough, then you will destroy the state of > the view >>> in the other tab as well somewhen. Usually after 20 requests (default). >>>> >>>> To come over this, we need to store the n last views not only per > session, >>> but also per browser tab (==windowId). >>>> Of course, there can be lots of fancy stuff done to detect closed > tabs, >>> etc. But all this is much more stable if we really have the opportunity > to >>> distinguish between tabs. We can e.g. also introduce a configuration > for maximum >>> allowed tabs, to reduce memory blasting. >>>> >>>> All this is actually completely independent of how the windowId > get's >>> created and checked imo. >>>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> PS: btw, a PhD student in my institute made me aware of a trick > with the >>> browser history. I think Jakob also already researched in this > direction: >>>> > https://github.com/balupton/history.js/wiki/Intelligent-State-Handling >>>> This mechanism does only 1 GET request (mine does 2), but with > pure AJAX >>> you imo cannot fully replace the header once the window is fully > loaded. Thus >>> you cannot easily handle dynamically loaded CSS, background images, etc > with >>> this approach. >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: Leonardo Uribe <[email protected]> >>>>> To: MyFaces Development <[email protected]> >>>>> Cc: >>>>> Sent: Thursday, November 17, 2011 9:39 PM >>>>> Subject: Re: [core extcdi] is required to create another > proposal about >>> windowId? >>>>> >>>>> Hi Gerhard >>>>> >>>>> Ok, good to know that. I'll work on a solution based on > the >>> previous >>>>> discussions about it to have more options in this case. >>>>> >>>>> regards, >>>>> >>>>> Leonardo Uribe >>>>> >>>>> 2011/11/17 Gerhard Petracek > <[email protected]>: >>>>>> hi leo, >>>>>> >>>>>> as soon as the new approach works, we can suggest it for > jsf 2.2. >>>>>> however, since it's only compatible with html5, we > have to >>> suggest a >>>>>> 2nd approach (e.g. the default behaviour of codi). >>>>>> >>>>>> regards, >>>>>> gerhard >>>>>> >>>>>> http://www.irian.at >>>>>> >>>>>> Your JSF powerhouse - >>>>>> JSF Consulting, Development and >>>>>> Courses in English and German >>>>>> >>>>>> Professional Support for Apache MyFaces >>>>>> >>>>>> >>>>>> >>>>>> 2011/11/17 Werner Punz <[email protected]>: >>>>>>> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe: >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> In the last days there was some work in these > issues: >>>>>>>> >>>>>>>> (EXTCDI-242) improve ClientSideWindowHandler > windowId >>> passing via >>>>> cookie >>>>>>>> (EXTCDI-241) Allow users of the > ClientSideWindowHandler to >>> specify >>>>> if >>>>>>>> it should get applied per Request >>>>>>>> (EXTCDI-240) Enhance ClientSideWindowHandler - > remove >>> flickering, >>>>> etc >>>>>>>> >>>>>>>> Just one question: if the flickering problem was > fixed on >>> the >>>>> current >>>>>>>> solution done on EXTCDI, it is still necessary to > create >>> an >>>>>>>> implementation inside myfaces core for windowId? > This >>> problem is on >>>>> my >>>>>>>> list of things to do, so it is better to ask > first. >>>>>>>> >>>>>>>> regards, >>>>>>>> >>>>>>>> Leonardo Uribe >>>>>>>> >>>>>>> Good question, I guess we need something for WindowID > handling >>> for >>>>> jsf2.2 >>>>>>> especially given in hindisght of what is planned for > 2.2 >>> according to >>>>> Ed >>>>>>> Burns blog but the final answer for now is up to the > CODI >>> guys. >>>>>>> >>>>>>> Werner >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Jakob Korherr >>> >>> blog: http://www.jakobk.com >>> twitter: http://twitter.com/jakobkorherr >>> work: http://www.irian.at >>> >> >
