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

Reply via email to