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