使用 rich:dataTable 制作可扩展/可折叠子表的最佳方法
我最近将一个应用程序从 JSF 1.1 移植到 JSF 1.2。 在此过程中，我们移除了战斧并决定使用 rich 来代替。
现在我需要一种方法来为表中的每一行创建可扩展/可折叠的详细信息Viev。
我唯一能想到的是沿着这些思路的东西（改编自 docs.jboss.com 的文档）：
<rich:dataTable value="#{capitalsBean.capitals}" var="capitals">
<rich:column>
...
</rich:column>
<rich:subTable value="#{capitals.details}" var="detail" ajaxKeys="#{bean.ajaxSet}" binding="#{bean.subtable}" id="subtable" rendered="detail.detailOpened">
<rich:column>
...
</rich:column>
</rich:subTable>
</rich:dataTable>
我想类似的东西会起作用。 问题是我要么必须向我使用的对象添加 getDetailOpened 和 setDetailOpened，要么将每个对象包装在提供这两种方法的另一个对象中。
有人知道更好的方法，或者应该如何完成？
I've recently ported an application from JSF 1.1 to JSF 1.2. In the process we removed tomahawk and decided to use rich instead.
Now I need a way to make an expandable/collapsible detailViev for each row in the table.
The only thing I can think of is something along these lines (adapted from documentation at docs.jboss.com):
<rich:dataTable value="#{capitalsBean.capitals}" var="capitals">
<rich:column>
...
</rich:column>
<rich:subTable value="#{capitals.details}" var="detail" ajaxKeys="#{bean.ajaxSet}" binding="#{bean.subtable}" id="subtable" rendered="detail.detailOpened">
<rich:column>
...
</rich:column>
</rich:subTable>
</rich:dataTable>
I guess something like that would work. The problem is that I either have to add a getDetailOpened and a setDetailOpened to the objects I use, or wrap each object in another object that provides those two methods.
Anybody knows a better way, or how it is supposed to be done?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我经常向包含这些属性的 Bean（或包装器 Bean）添加方法，作为处理 JSF 的一种方式。 它不漂亮，但很有效。
目前我能想到的唯一其他选择是使用 JavaScript 函数来切换详细信息视图的状态。 由于多种原因，这并不理想，但它可以让您不必在服务器端保留状态。
I've often added methods to my beans (or wrapper beans) which contain those properties as a way of working around JSF. It's not pretty but it works.
The only other option I can think of at the moment is to use a JavaScript function to toggle the state of the details view. That wouldn't be ideal for a number of reasons but it would save you having to keep state server-side.