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