Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: EE-3.0.0.GA
-
Component/s: Facelet Components
-
Labels:None
-
Environment:JSF 2.x / IF 2.x
-
Workaround Exists:Yes
-
Workaround Description:HideThe only "work-around" I've seen online thus far is avoiding the issue by writing tables with h:column exposed:
<h:dataTable>
<h:column>#{data.one}</h:column>
<h:column><cc:superColumn>#{data.two}</cc:superColumn></h:column>
</h:dataTable>ShowThe only "work-around" I've seen online thus far is avoiding the issue by writing tables with h:column exposed: <h:dataTable> <h:column>#{data.one}</h:column> <h:column><cc:superColumn>#{data.two}</cc:superColumn></h:column> </h:dataTable>
Description
<h:dataTable value="#{someBean.someData}" var="data">
<h:column>#{data.one}</h:column>
<cc:superColumn>#{data.two}</cc:superColumn>
</h:dataTable>
Where it is expected that composite-component abstracted tags are visible to the parents.
However, only the normal h:column displaying the #{data.one} binding will be rendered.
-
Hide
- CompositeColumnTCTest.war
- 6.02 MB
- Nils Lundquist
-
- META-INF/MANIFEST.MF 0.0 kB
- WEB-INF/classes/.../icesoft/TestModel.class 1.0 kB
- WEB-INF/classes/.../TestService.class 1 kB
- WEB-INF/faces-config.xml 0.3 kB
- WEB-INF/lib/commons-beanutils.jar 226 kB
- WEB-INF/lib/commons-collections.jar 558 kB
- WEB-INF/lib/commons-digester.jar 140 kB
- WEB-INF/lib/commons-lang.jar 240 kB
- WEB-INF/lib/commons-logging.jar 52 kB
- WEB-INF/lib/icefaces-compat.jar 2.53 MB
- WEB-INF/lib/icefaces.jar 179 kB
- WEB-INF/lib/icepush.jar 234 kB
- WEB-INF/lib/jsf-api.jar 601 kB
- WEB-INF/lib/jsf-impl.jar 1.81 MB
- WEB-INF/web.xml 2 kB
- index.jsp 0.1 kB
- resources/test/col.xhtml 0.7 kB
- test.xhtml 1 kB
-
Hide
- CompositeColumnTCTest.war
- 6.02 MB
- Nils Lundquist
-
- META-INF/MANIFEST.MF 0.0 kB
- WEB-INF/classes/.../icesoft/TestModel.class 1.0 kB
- WEB-INF/classes/.../TestService.class 1 kB
- WEB-INF/faces-config.xml 0.3 kB
- WEB-INF/lib/commons-beanutils.jar 226 kB
- WEB-INF/lib/commons-collections.jar 558 kB
- WEB-INF/lib/commons-digester.jar 140 kB
- WEB-INF/lib/commons-lang.jar 240 kB
- WEB-INF/lib/commons-logging.jar 52 kB
- WEB-INF/lib/icefaces-compat.jar 2.53 MB
- WEB-INF/lib/icefaces.jar 179 kB
- WEB-INF/lib/icepush.jar 234 kB
- WEB-INF/lib/jsf-api.jar 601 kB
- WEB-INF/lib/jsf-impl.jar 1.81 MB
- WEB-INF/web.xml 2 kB
- index.jsp 0.1 kB
- resources/test/col.xhtml 0.8 kB
- test.xhtml 1 kB
Issue Links
- blocks
-
IPCK-126 icefaces-composite-comps.jar with JSF/ICEfaces 2.0 Compat
- Closed
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
That looks like an excellent technique. Please try it out.
Another approach would be to implement a TagHandler, but that will be more complex – the componentType attribute should allow the Renderer to remain a facelet while the backing component is the desired class. A custom TagHandler would require implementation of all three parts (tag, Component, and Renderer).
After using a backing component to identify our composite component as UIColumn to the DataTable, our composite component appears to behave just a a regular h:column would.
However for composite components to be worthwhile, we need to make use of the cc:insertChildren tag; the composite component tag responsible for the copying of using-page tag-children into the CC. This is performed by the RelocateChildrenListener (a RelocateListener subclass) listening for the PostAddToViewEvent.
Unfortunately, UIColumn already performs a relocation like this by default, duplicating its contents repeatedly into the respective column of each row. This is performed by com.sun.faces.renderkit.html_basic.BaseTableRenderer during component encoding, which appears to occur after PostAddToViewEvent.
These two events clash and cause the unpredictable encoding of column and CC contents. With cc:insertChildren removed, the default Column behaviour works. With it present, sometimes the default Column behaviour will display on a re-render (ex. after pressing a button), but normally nothing appear in the column cells.
The children of the using page appear to be being blanked by the cc:insertChildren event, and when the Column encoding gets to them, there is nothing to render. This is judging from the firing order of the events and the many additional calls to getChildrenCount() (of my backing component) that all return 0, which aren't present when cc:insertChildren is absent.
Failing that a solution can be found to the column issues, a workaround could be using two tag-libs in the ice-cc jar, one using the new composite component interface sans tables, and one using the older style table components.
Moving to beta 2, doesn't effect the compat version.
working as expected now with JSF 2.1
The attached example should render the numbers 0-29 in 3 columns and 10 rows, but one of the columns is defined by a composite component and isn't rendered.