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