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