Details
-
Type: Bug
-
Status: Open
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: EE-3.3.0.GA
-
Fix Version/s: None
-
Component/s: Framework
-
Labels:None
-
Environment:WebSphere Portal
Description
With WebSphere Portal, when a component sends an Ajax request it can either trigger normal or subtree rendering. When doing a subtree render, things seems to behave and the resulting response is properly targeted at the relevant part of the view. However, when "normal" rendering is triggered (i.e. render=@all) the resulting response is the entire view, starting with the <html> tag. This causes problems on the client side when it attempts to replace the view with the response and the portlet ends up being emptied.
Normally the old DOM would be compared to the new DOM and the resulting updates would be properly calculated. Part of the problem is related to the problem described in IPCK-479 where the ViewMap does not contain a reference to the previous DOM.
However, we do have logic added fromICE-8379 that should, when the old DOM is unavailable, regenerate the current view and replace the contents of the portlets. However this logic is currently not working in WebSphere Portal as the resulting response is a full <html> page and unsuited to being found and replaced in the client's DOM.
Normally the old DOM would be compared to the new DOM and the resulting updates would be properly calculated. Part of the problem is related to the problem described in IPCK-479 where the ViewMap does not contain a reference to the previous DOM.
However, we do have logic added from
Mojarra 2.1.6 works without the fix to the DOMPartialViewContext that I have for this case.
Mojarra 2.2.21 works with the fix to the DOMPartialViewContext that I have for where I find the div with the the unique portlet id instead of finding and using the document element as the contents of the view.
So the fix is unnecessary (but benign) when running the older version of Mojarra and helps it work when running with the newer Mojarra.