There seems to be a consensus in the JSF community that the best way to
do this is to invoke
an action which takes care of actually fetching the data, making the
getter merely a POJO-style
getter.
Eg.
public class UserList extends BasePage implements Serializable {
private static final long serialVersionUID = 972359310602744018L;
private List users;
public UserList() {
setSortColumn("username");
}
// ensure this action is invoked prior to fetching
public String openUserList() {
users = sort(userManager.getUsers(null));
return "success";
}
public List getUsers() {
return users;
}
}
I won't argue this is the best solution, but as JSF is strange in many
ways far beyond the realm of this issue,
I've come to accept it to be a better solution than actually fetching
the data from the database multiple times.
Safurudin
Matt Raible skrev:
I'm OK with changing UserList to be a better example. What do you
suggest we change it to?
Matt
On 7/30/07, Safurudin <[EMAIL PROTECTED]> wrote:
According to Veniamin Goldins and Ed Burns on the following thread:
http://forum.java.sun.com/thread.jspa?threadID=550485&messageID=3919330
one shoudn't expect getters of managed-beans only to be invoked once
per request/lifecycle
In Appfuses eg. UserList.java following happens;
public List getUsers() {
return sort(userManager.getUsers(null));
}
As the JSF spec doesn't guarantee that the getters will be called only
once, this could lead to the same query getting
executing multiple times during the JSF lifecycle, eg. validate and
render-response.
It is not critical for such a simple example as in the UserList, but if
you have a lot of getters on a page, then equally many
queries can be executed unnecessarily due to this issue (first-hand
experience)
I believe this should be revised in Appfuse, because this could become a
potential performance leak if enough objects/beans
are involved in a single page rendering. Users don't expect appfuses
examples to do unnecessary query executions.
Any comments are appreciated.
Regards,
Safurudin Mahic
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
