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