I think i understand know what lazy should do... Our windowhandler.js just checks if window.name is empty, removes the windowId and redirects to the same url without a windowId.
But we must also do another check if the mode is LAZY because it currently don't validate the windowId. If you a page in a new tab -> test.xhtml?windowId=1 it checks that the window.name is empty and redirects to test.xhtml?windowId= The server will now redirect to: text.xhtml?windowId=someNewAndValidWIndowId What appens now if you open this in the same tab: test.xhtml?windowId=3 nothing! #assertWindowId must also take care of this. What should happen? Reload/redirect via the windowId stored in window.nameor doing a redirect without windowId (assigning a new windowId to the tab)? I would rename URL to LAZY (merge these modes) and fix this small bug above. Any objections? 2014/1/13 Thomas Andraschko <andraschko.tho...@gmail.com> > Mark, i understand the windowhandler.html approach but i still don't > understand LAZY. > You said that it's the same as URL but with some JS checks. > I tried to explain my thoughts about a LAZY in my last email in the "JSF - > default ClientWindowRenderMode?" thread. > I really completely understand the logic for CLIENTWINDOW but it would be > nice, if you could explain what exactly should happen on client side if the > LAZY mode is used. > > URL is just for appending the windowId to the url's without any JS - like > the default mode in CODI. > If LAZY requires JS, then it's a different mode IMO because the current > windowhandling also makes the target attribute of links unusable. Isn't it? > > > > 2014/1/13 Mark Struberg <strub...@yahoo.de> > >> LAZY is really exactly the same as you mean with 'URL'. I just like the >> term 'LAZY' more than 'URL' as it explains much better what happens. >> >> Please read the very last paragraph in >> >> http://myfaces.apache.org/orchestra/multiwindow.html >> >> Afaik, this was written by Mario Ivankovic (main-brain of Orchestra) and >> Werner Punz (_the_ JSF spec JavaScript wizzard) back in the days when they >> did Apache MyFaces Orchestra. >> >> The 100% solution is the ClientWindow mode. But this has the downside of >> the intermediate page... >> >> LieGrue, >> strub >> >> >> >> >> > On Sunday, 12 January 2014, 22:25, Thomas Andraschko < >> andraschko.tho...@gmail.com> wrote: >> > > Here is my idea about the initial refactoring on the windowhandler.js >> > >> > https://gist.github.com/tandraschko/3d2aa9d84f6469206ce7 >> > >> > I think it will need some more refactoring/fixing when we finally know >> what >> > LAZY should do. >> > But i like to structure and the single entry point via >> DSWindowContext#init. >> > >> > Also storeEvent seems the be unused? Could anyone explain this to me? >> > >> > >> > >> > 2014/1/10 Gerhard Petracek <gerhard.petra...@gmail.com> >> > >> >> (similar to what we have in codi) we can do a lazy restore in >> addition (if >> >> it is limited to the url/lazy mode). >> >> >> >> regards, >> >> gerhard >> >> >> >> >> >> >> >> 2014/1/10 Thomas Andraschko <andraschko.tho...@gmail.com> >> >> >> >> > (of course it would only be required #ifPostback) >> >> > >> >> > >> >> > 2014/1/10 Thomas Andraschko <andraschko.tho...@gmail.com> >> >> > >> >> > > Hmm right - but we could also move windowContext#activateWindow >> > to a >> >> > > AFTER_RESTORE_VIEW phase listener? >> >> > > AFAIK RESTORE_VIEW shouldn't touch any beans? >> >> > > >> >> > > >> >> > > 2014/1/10 Gerhard Petracek <gerhard.petra...@gmail.com> >> >> > > >> >> > >> we need to restore the window-id before the lifecycle starts. >> >> > >> >> >> > >> regards, >> >> > >> gerhard >> >> > >> >> >> > >> >> >> > >> >> >> > >> 2014/1/10 Thomas Andraschko >> > <andraschko.tho...@gmail.com> >> >> > >> >> >> > >> > but why should we keep the JS logic instead of ViewMap? >> >> > >> > Are there any drawbacks when we store it in the ViewMap? >> >> > >> > >> >> > >> > The current implementations looks soo complex, but >> > actually it isn't >> >> > >> that >> >> > >> > complex. So therefore i would like to get rid of not >> > required code. >> >> > >> > >> >> > >> > >> >> > >> > 2014/1/10 Gerhard Petracek >> > <gerhard.petra...@gmail.com> >> >> > >> > >> >> > >> > > as a (deactivatable) fallback the view-map would be >> > fine (we >> >> > couldn't >> >> > >> use >> >> > >> > > it in codi, because we had to support jsf 1.2.x as >> > well) >> >> > >> > > >> >> > >> > > regards, >> >> > >> > > gerhard >> >> > >> > > >> >> > >> > > >> >> > >> > > >> >> > >> > > 2014/1/10 Mark Struberg <strub...@yahoo.de> >> >> > >> > > >> >> > >> > > > we probably should do both. >> >> > >> > > > >> >> > >> > > > LieGrue, >> >> > >> > > > strub >> >> > >> > > > >> >> > >> > > > >> >> > >> > > > >> >> > >> > > > >> >> > >> > > > ----- Original Message ----- >> >> > >> > > > > From: Thomas Andraschko >> > <andraschko.tho...@gmail.com> >> >> > >> > > > > To: "dev@deltaspike.apache.org" >> > <dev@deltaspike.apache.org> >> >> > >> > > > > Cc: >> >> > >> > > > > Sent: Friday, 10 January 2014, 16:56 >> >> > >> > > > > Subject: Re: Ideas on ClientWindow >> > handling / refactoring >> >> > >> > > > > >> >> > >> > > > > Saving the windowId for postbacks in the >> > ViewMap, would be >> >> > really >> >> > >> a >> >> > >> > > much >> >> > >> > > > > easier, more compatible and safer way >> > than adding hidden >> >> inputs >> >> > >> via >> >> > >> > JS. >> >> > >> > > > > >> >> > >> > > > > >> >> > >> > > > > >> >> > >> > > > > 2014/1/10 Thomas Andraschko >> > <andraschko.tho...@gmail.com> >> >> > >> > > > > >> >> > >> > > > >> Hi Gerhard, >> >> > >> > > > >> >> >> > >> > > > >> thats true. Therefore we added extra >> > processing of >> >> > >> > > > >> >> > javax.faces.ViewState+javax.faces.ClientWindow in PrimeFaces >> >> > :) >> >> > >> > > > >> Don't know if Cagatay would >> > accept that i add workarounds >> >> for >> >> > >> DS in >> >> > >> > > > >> PrimeFaces. Therefore adding the >> > windowId e.g. to the >> >> ViewMap >> >> > >> would >> >> > >> > > be >> >> > >> > > > a >> >> > >> > > > >> safer way. >> >> > >> > > > >> >> >> > >> > > > >> Regards, >> >> > >> > > > >> Thomas >> >> > >> > > > >> >> >> > >> > > > >> >> >> > >> > > > >> 2014/1/10 Gerhard Petracek >> > <gerhard.petra...@gmail.com> >> >> > >> > > > >> >> >> > >> > > > >>> @thomas: >> >> > >> > > > >>> with jsf 2.2+ it's >> > different. >> >> > >> > > > >>> the window-id is (/should be) >> > also used (if enabled) to >> >> find >> >> > >> the >> >> > >> > > > > correct >> >> > >> > > > >>> state. >> >> > >> > > > >>> -> any compliant request >> > needs to include the window-id (if >> >> > >> > > > > enabled). >> >> > >> > > > >>> >> >> > >> > > > >>> regards, >> >> > >> > > > >>> gerhard >> >> > >> > > > >>> >> >> > >> > > > >>> >> >> > >> > > > >>> >> >> > >> > > > >>> 2014/1/10 Thomas Andraschko >> > <andraschko.tho...@gmail.com> >> >> > >> > > > >>> >> >> > >> > > > >>> > Based on the discussion in >> > "JSF - default >> >> > >> > > > > ClientWindowRenderMode?": >> >> > >> > > > >>> > >> >> > >> > > > >>> > >> struberg: >> >> > >> > > > >>> > >> The windowId is >> > added as root element to the view >> >> tree. >> >> > >> > > > >>> > >> >> > >> > > > >>> > You mean that the >> > dsPostWindowId input is added as direct >> >> > >> form >> >> > >> > > > > child. >> >> > >> > > > >>> > Right? >> >> > >> > > > >>> > >> >> > >> > > > >>> > Posting it with default >> > ajax options should work fine >> >> with >> >> > >> > > > > PrimeFaces. >> >> > >> > > > >>> > The only difference is our >> > partialSubmit modus, which >> >> only >> >> > >> > > > > collects the >> >> > >> > > > >>> > values from the processed >> > components. >> >> > >> > > > >>> > So if you only process e.g. >> > "input1 input2", the hidden >> >> > >> > > > > inputs on the >> >> > >> > > > >>> form >> >> > >> > > > >>> > won't processed. >> >> > >> > > > >>> > Updating the ViewState is a >> > custom logic with >> >> > partialSubmit. >> >> > >> > > > >>> > >> >> > >> > > > >>> > Maybe it should be handled >> > better on PrimeFaces side but >> >> I >> >> > >> think >> >> > >> > > > > it >> >> > >> > > > >>> would >> >> > >> > > > >>> > be better the store the >> > windowId in the >> >> WindowIdComponent. >> >> > >> > > > >>> > It works for all cases and >> > it don't requires any JS or >> >> > >> > > > > compontlib >> >> > >> > > > >>> > compatibility. >> >> > >> > > > >>> > It's just stored the >> > windowId in the ViewRoot which is >> >> > always >> >> > >> > > > > available >> >> > >> > > > >>> for >> >> > >> > > > >>> > postbacks. >> >> > >> > > > >>> > Or will it have other >> > drawbacks? >> >> > >> > > > >>> > >> >> > >> > > > >>> > >> >> > >> > > > >>> > About >> > windowhandler.js/html: >> >> > >> > > > >>> > What about moving the whole >> > JS stuff to the >> >> > windowhandler.js? >> >> > >> > > > >>> > We could parse the >> > windowhandler html string on the >> >> server >> >> > >> and >> >> > >> > > > > parse JSF >> >> > >> > > > >>> > resource includes. So we >> > could easily include our >> >> > >> > > > > windowhandler.js. >> >> > >> > > > >>> > The user can also import >> > other resources like css. >> >> > >> > > > >>> > >> >> > >> > > > >>> > I already done this for a >> > custom JSF 2.2 ClientWindow - >> >> > works >> >> > >> > > > > fine. >> >> > >> > > > >>> > >> >> > >> > > > >>> > I think we should also >> > render the ClientWindowRenderMode >> >> to >> >> > >> the >> >> > >> > > > > client, >> >> > >> > > > >>> so >> >> > >> > > > >>> > that the windowhandler only >> > handles CLIENTWINDOW and not >> >> > e.g. >> >> > >> > URL. >> >> > >> > > > >>> > I would refactor the >> > windowhandler.js, that it must be >> >> > >> > initialized >> >> > >> > > > > via >> >> > >> > > > >>> a JS >> >> > >> > > > >>> > call -> >> > DSWindowContext.init(windowId, >> >> > >> clientWindowRenderMode); >> >> > >> > > > >>> > We could simply render that >> > script via our >> >> > >> > > > >>> WindowIdComponentHtmlRenderer. >> >> > >> > > > >>> > >> >> > >> > > > >>> >> >> > >> > > > >> >> >> > >> > > > >> >> >> > >> > > > > >> >> > >> > > > >> >> > >> > > >> >> > >> > >> >> > >> >> >> > > >> >> > > >> >> > >> >> >> > >> > >
