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