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. > >> > >> > > > >>> > > >> > >> > > > >>> > >> > >> > > > >> > >> > >> > > > >> > >> > >> > > > > > >> > >> > > > > >> > >> > > > >> > >> > > >> > >> > >> > > > >> > > > >> > > >> > > >
