Richfaces 4.0 dataTables models implementation discussion
Hi,
As all of you know in the richfaces 4.0.0 were proposed provide two dataTables component instead of combine all features to the one high featured component. These components are:
1. SimpleDataTable - light-weight component with simple table functionality with table based markup.
2. ExtendedDataTable - complex but high featured component with fully div based markup.
see wiki article article
During implementation discussion were proposed two points of view for the data model processing implementation:
1. Use existing dataModels from the 3.3.X with needed fixes for the JSF2.0 api. Fix selection bug when sorting changes, add grouping feature for the subtables.
+ there is a well tested code what should be refactored for the richfaces 4.0.0.
- user should implement custom dataModels which extend our models if he want implement specific behaviors;
2. Proposed by Nick. Create some kind of visual data model where will be stored current states for the selection/grouping/filtering etc. for each column and provide api for work with these functionality. For example there is a simple bean, which contains List of some fooObjects and implements method for the sortEvent processing
@ManagedBean(name="sampleBean")
@SessionScoped
public class SampleBean {
private List <FooObject> fooData;
private VisualModel visualModel;
public sortListener(SortEvent event) {
String direction = visualMoldel.getSortDirection();
// do fooData sorting
}
}
dataTable with sorting controls which support asc/desc sorting.
<rich:dataTable visualModel="#{sampleBean.visualModel}" listener="#{sampleBean.sortListener}" value="#{sampleBean.fooData}">
User click on sorting control, sort event fired and sortListener method called in this method user should get sort direction from the visual model and do sort for the list of data objects. The same way grouping and filtering features could be implemented
+ There is now need for the user to implement custom data models, he could use standard JSF dataModels. (Some kind of functionality to bind row key with the object is still required. Probably, in a variant of extended rowKeyConverter - this should be designed to work on EJB side and use only API dependencies.)
- All works relating to sorting/filtering/grouping etc. should be implemented by user himself.
Thoughts which way we should choose are welcome
