Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.1-Beta
-
Component/s: ICE-Components
-
Labels:None
-
Environment:Tomcat v7.0. JSF 2.1.3.
-
Workaround Exists:Yes
-
Workaround Description:Use HTML <img> tag for images and h: tags for grid and panels.
Description
There's two issues, icefaces tags do not render when embedded in an ace panelExpansion and nor does the h:graphicImage and ice:graphicImage.
Test cases:
1. Using all icefaces tags within an ace:panelExpansion tags and HTML <img> for images causes the following error (test with auctionMonitor.xhtml):
Oct 19, 2011 9:26:21 AM com.icesoft.faces.context.DOMContext attachDOMContext
SEVERE: ICEfaces rendering required by icefaces-compat.jar components. Enable via <icecore:config render="true" />.
Oct 19, 2011 9:26:21 AM org.icefaces.impl.context.CustomPartialRenderCallback visit
SEVERE: Subtree rendering failed for class org.icefaces.ace.component.datatable.DataTable iceForm:iceTablejava.lang.UnsupportedOperationException: ICEfaces rendering required.
2. Using all JSF tags within an ace:panelExpansion tags causes the following error (test with auctionMonitor2.xhtml):
Oct 19, 2011 9:27:01 AM org.icefaces.impl.context.CustomPartialRenderCallback visit
SEVERE: Subtree rendering failed for class org.icefaces.ace.component.datatable.DataTable iceForm:iceTablejava.lang.UnsupportedOperationException: Implement writeURIAttribute
3. Using all icefaces tags within an ace:panelExpansion tags causes the following error (test with auctionMonitor3.xhtml):
Oct 19, 2011 9:27:38 AM com.icesoft.faces.context.DOMContext attachDOMContext
SEVERE: ICEfaces rendering required by icefaces-compat.jar components. Enable via <icecore:config render="true" />.
Oct 19, 2011 9:27:38 AM org.icefaces.impl.context.CustomPartialRenderCallback visit
SEVERE: Subtree rendering failed for class org.icefaces.ace.component.datatable.DataTable iceForm:iceTablejava.lang.UnsupportedOperationException: ICEfaces rendering required.
4. Using all JSF tags within an ace:panelExpansion tags and HTML <img> for images render succesfully (test with auctionMonitor4.xhtml):
-
Hide
-
-
META-INF/MANIFEST.MF
-
auction_styles.css
-
auctionControl.jspx
-
auctionControl.xhtml
-
auctionMonitor.html
-
auctionMonitor.jspx
-
auctionMonitor.xhtml
-
auctionMonitor2.xhtml
-
auctionMonitor3.xhtml
-
auctionMonitor4.xhtml
-
css/auction_styles.css
-
css/demo_template.css
-
css/images/banner_bg.gif
-
css/images/banner_hdr_auction.jpg
-
css/images/banner_logo.jpg
-
css/images/bgslice_footer.gif
-
css/images/bgslice_footer.jpg
-
css/images/footer_faces.jpg
-
errorPage.html
-
images/blue-fade-bkgnd.gif
-
images/button_arrow_bottom.gif
-
images/button_arrow_down.gif
-
images/button_arrow_top.gif
-
images/button_arrow_up.gif
-
images/button_bid.gif
-
images/button_bid_accept.gif
-
images/button_bid_decline.gif
-
images/button_bkgnd.gif
-
images/button_bkgnd2.gif
-
images/button_orange_120x22.gif
-
-
Issue Links
- depends on
-
ICE-7089
Eliminate use of DOMContext
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Assign to Ted for analysis.
The first incompatibility with compat components is likely due to the need to move them to response-writer based renderers. However, the second failure that uses all h: components needs analysis.
There's not much to analyze – if the ACE panel is using customUpdate, the DOMResponseWriter will not be enabled for that render pass, and the compat components will not function.
It seems unlikely that an accordion panel really needs customUpdate, however. Instead, it could use subtree rendering which would support compat components on an ICEfaces page.
Investigating the following: use standard ResponseWriter for custom updates. Note that custom updates will typically not be compatible with general updates detected via DOM diff and full page rendering.
— src/main/java/org/icefaces/impl/context/DOMPartialViewContext.java (revision 26064)
+++ src/main/java/org/icefaces/impl/context/DOMPartialViewContext.java (working copy)
@@ -578,10 +578,16 @@
.getPartialViewContext().getPartialResponseWriter();
ResponseWriter originalWriter = facesContext.getResponseWriter();
- ResponseWriter updateWriter = new BasicResponseWriter(
+// ResponseWriter updateWriter = new BasicResponseWriter(
+// facesContext.getExternalContext().getResponseOutputWriter(),
+// originalWriter.getCharacterEncoding(),
+// originalWriter.getContentType() );
+System.out.println("original writer content type " + originalWriter.getContentType());
+ ResponseWriter updateWriter = facesContext.getRenderKit()
+ .createResponseWriter(
facesContext.getExternalContext().getResponseOutputWriter(), - originalWriter.getCharacterEncoding(),
- originalWriter.getContentType() );
+ "text/html",
+ originalWriter.getCharacterEncoding() );
facesContext.setResponseWriter(updateWriter);
Map extensionAttributes = new HashMap();
extensionAttributes.put("id", clientId);
2. is resolved: customUpdate processing is now using a full ResponseWriter provided by the implementation. BasicResponseWriter is not intended for use for arbitrary component rendering, it is only intended for cases where a ResponseWriter interface is required, but the use is essentially that of a Writer.
To observe the conflict between D2D render @all and custom update, use the sort headings in conjunction with expand/collapse. The panelExpansion can be implemented to not use customUpdate and instead use subtree rendering.
Only 2. is resolved, so as the JIRA stands it cannot be closed until 1. and 3. are also resolved.
This fix is causing a regression in ICE-7389 due to JavaScript escaping problems.
The fix has been modified so that startCDATA is invoked on the inner ResponseWriter (the one passed to the component rendering) rather than the outer PartialResponseWriter. When invoked on the outer PartialResponseWriter, the component rendering had no awareness of the active CDATA section and was not properly escaping the CDATA sections generated by components.
Both ICE-7364 and ICE-7389 are now running without Exceptions, however they do still have problems due to conflict between D2D rendering and customUpdate.
To my understanding our ResponseWriter should be implementing "writeURIAttribute", in case 2, and ICEfaces-enabled rendering in the other cases. I can only imagine this stem from some interaction with customUpdate and other core features.