Question

In two other questions (here and here) BalusC makes a straight up declaration:

Getters are solely there to access bean properties, not to do some business logic. There you have the bean constructor, initialization blocks or event methods for. All are executed only once during bean’s life and that’s exactly what you want.

Well gee — this just invalidated a gazillion lines of code I have already written. Ok, then, what is the correct way of implementing a backing bean that fills a data table? I understand his point and the concept, but not the practice. My question is twofold:

1. Why is the way I am doing it wrong?
2. How do I fix it?

I use PrimeFaces p:dataTable a lot, and it’s value attribute resolves to a collection. For reasons I don’t go into here, I do not use PrimeFaces’ lazy table loading feature. Instead I implement my own filter/sort controls, but they trigger AJAX events, which then results in the table being filled with records fetched from the data base.

The table is marked up like this:

 <p:panel id="mqTable">

   <h:outputText value="Sort/Filter: #{maintCategory.tableQueryParameters}" />

   <p:dataTable
      id="mqDataTable"
      rows="#{maintCategory.pageSize}"
      value="#{maintCategory.dataModel}"
      selection="#{maintCategory.selected}"
      var="cat"
      selectionMode="single"
      emptyMessage="No Categories Found">

Now the INCREDIBLY BAD UN-JSFish (or so I just found out) getter for dataModel goes like this:

public ATMDataModel getDataModel() {
    TableQueryParameters p = getTableQueryParameters();
    if (p.isChangePending()) clearDataModel();
    p.setChangePending(false);
    if (dataModel != null) return dataModel;
    List<ET> list = getDAO().runQuery(p);
    if (p.isNeedResultSize()) p.setResultSize(getDAO().runQueryCount(p));
    dataModel = new ATMDataModel(list);
    return dataModel;
}

A few explanations.

1. This is from an abstract super-class where ET is the “Entity Type.” All my CRUDs use this same routine.
2. The class ATMDataModel is a wrapper for the list which implements SelectableListModel. The row selection logic in PrimeFaces requires this. (It is a pain that appeared in PF 3 but it makes row selection work more reliably.)
3. The class TableQueryParameters is something I wrote to encapsulate the current state of the table on the user’s screen. It includes what sort parameters, what filter parameters, what page we are on, etc. Because this needs to be preserved, the backing bean is ViewAccesScoped (via MyFaces CODI) and the TableQueryParameters is a property within it.
4. The TableQueryParameters are updated in response via AJAX events, which also update the form causing getDataModel to be called. The method isChangePending goes true when anything changes. So the getDataModel method uses this to generate only one fetch from the DAO between changes no matter how many times it is called.

BUT if the TableQueryParameters do change, I have to call runQuery with those parameters to fetch the new set of records the user wants to see. If I don’t call it in getDataModel where do I call it?

Please advise.

Answer 1

You’re basically lazily loading the data in the getter. You’re not hitting the DB on every getter call within the same request (or view) scope. This is affordable. I don’t use CODI, but I’d imagine that the getTableQueryParameters() call is also particularly cheap and nothing to worry about.

As to the concrete question, you’d normally do the DB/business job in an action(listener) method which is attached to the UICommand component and/or the ajax event tag.

For example (works also as <p:commandButton action> though)

<p:ajax listener="#{bean.deleteSelectedRow}" />
...
<p:ajax listener="#{bean.saveRowDetail}" />

with

public void deleteSelectedRow() {
    someService.delete(selectedRow);
    dataModel = loadDataModel();
}

public void saveRowDetail() {
    someService.save(selectedRow);
    dataModel = loadDataModel();
}

Depending on the meaning of p.isChangePending(), I think you could also get rid of it this way, it look like that you were setting it in the action(listener) methods.