So, if you have only one a4j:include, the same stuff work well. Right?
Yes, thats partialy right. If the include is the last element on the page, then it works very well.
If the include is at the beginning of the page, the same strange effects appear. When I have only one include, no problem, I place it at the botom and all works fine.
But when there are two or more includes, the problems appear.
a4j:include replaces the part of the DOM with the content of the new view.
if you say there is no problem to put to the end of the page it might mean that particular content of the included view breaks the layout.
So, can you try to have the include part as simple as possible and see does it depends of the content or a4j:include cracks the page in any case.
P.S. I hope you have no own <f:view> in the include?
I've no <f:view> in the include, but a <f:subview>.
OK, I checked complexity, it doesn't matter. As soon as there is a single input or output in the include it smashes the whole page.
But I found an interresting effect: if I assign manually to every component in the include an id, then all works fine...
As soon as there are more complex components in the include (like a tree), this is not really practicable.
At least, one known problem is present :
With different content of included pages, you have different number of components in a JSF view tree. As a result, generated Id's of components after <a4j:include> can be different from element id's in client-side DOM tree.
As a workaround, you can manually set id of all important components in a page :
- action/input components.
- data tables