Sounds reasonable. At least it is possible with HTML5 to do the following:
1) URL: index.xhtml?requestId=xyz 2) HTML5: change to index.xhtml without reloading (see [1]) Regards, Jakob [1] http://spoiledmilk.dk/blog/html5-changing-the-browser-url-without-refreshing-page 2011/11/20 Mark Struberg <strub...@yahoo.de>: > woah, just had a crazy idea! > > The root of all evil with the FlashScoped is that fact that we use cookies > for transporting the requestToken, right? > > With HTML5 browsers we could also just add the reqeustToken to the GET > request and use the html5 history API to cleanup the URL later. > Should work, right? Jakob, you have done some work in this area, does this > sound reasonable? > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Leonardo Uribe <lu4...@gmail.com> >> To: MyFaces Development <dev@myfaces.apache.org>; Mark Struberg >> <strub...@yahoo.de> >> Cc: >> Sent: Saturday, November 19, 2011 12:05 AM >> Subject: Re: [core extcdi] is required to create another proposal about >> windowId? >> >> 2011/11/18 Mark Struberg <strub...@yahoo.de>: >>>> 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... >>> >> >> Yes, the idea could be to generate a request id together with the >> windowId (in fact the proposal in the wiki mentions generate a >> windowId and a requestId). Since the spec already provide an interface >> to implement Flash scope (javax.faces.context.Flash abstract class), >> there is no need to create another interface to fill the gap between >> requestId management and Flash object, instead create an alternate >> Flash scope object, reusing the original code and fixing the parts >> related to cookie management with the alternate code. Note Flash scope >> "changes" before render response phase, so you need to do some >> handling between the current and the next requestId. >> >>> LieGrue, >>> strub >>> >>> >>> ----- Original Message ----- >>>> From: Leonardo Uribe <lu4...@gmail.com> >>>> To: MyFaces Development <dev@myfaces.apache.org>; Mark Struberg >> <strub...@yahoo.de> >>>> 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 <strub...@yahoo.de>: >>>>> 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 <jakob.korh...@gmail.com> >>>>>> To: MyFaces Development <dev@myfaces.apache.org>; Mark >> Struberg >>>> <strub...@yahoo.de> >>>>>> 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 <strub...@yahoo.de>: >>>>>>> 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 <lu4...@gmail.com> >>>>>>>> To: MyFaces Development >> <dev@myfaces.apache.org> >>>>>>>> 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 >>>> <gerhard.petra...@gmail.com>: >>>>>>>>> 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 >> <werner.p...@gmail.com>: >>>>>>>>>> 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 >>>>>> >>>>> >>>> >>> >> > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
