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