+1 for merging them and without the js it still works (like the default-mode of codi).
regards, gerhard 2014/1/14 Thomas Andraschko <andraschko.tho...@gmail.com> > +1 for keeping URL and LAZY? :) > > > 2014/1/14 Gerhard Petracek <gerhard.petra...@gmail.com> > > > +1 > > > > regards, > > gerhard > > > > > > > > 2014/1/14 Thomas Andraschko <andraschko.tho...@gmail.com> > > > > > Hi Gerhard, > > > > > > LAZY mode without adding ds:windowId will exactly work like URL. > > > But it will never have a chance to detect new windows. > > > We could also keep LAZY and URL, doesn't matter for me :) > > > > > > The main goal of the last email to clarify what the LAZY script part > > should > > > do and that it currently has an bug. > > > > > > Regards, > > > Thomas > > > > > > > > > 2014/1/14 Gerhard Petracek <gerhard.petra...@gmail.com> > > > > > > > imo we should keep one mode which works without js. > > > > > > > > regards, > > > > gerhard > > > > > > > > > > > > > > > > 2014/1/14 Thomas Andraschko <andraschko.tho...@gmail.com> > > > > > > > > > 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. > > > > > >> >> > >> > > > >>> > > > > > > >> >> > >> > > > >>> > > > > > >> >> > >> > > > >> > > > > > >> >> > >> > > > >> > > > > > >> >> > >> > > > > > > > > > >> >> > >> > > > > > > > > >> >> > >> > > > > > > > >> >> > >> > > > > > > >> >> > >> > > > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > >> >> > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >
