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