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