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