search
Login

Categories


C Books Guide and List
C++ Books Guide and List
Best Java Books

3.8k questions

4k answers

117 comments

10.7k users

0 votes
206 views
asked Guru 27.1k points 31 47 92

2 Answers

0 votes
This is caused by the nature of deferred expressions #{} (note that "legacy" standard expressions ${} behave exactly the same when Facelets is used instead of JSP). The deferred expression is not immediately evaluated, but created as a ValueExpression object and the getter method behind the expression is executed everytime when the code calls ValueExpression#getValue().

This will normally be invoked one or two times per JSF request-response cycle, depending on whether the component is an input or output component (learn it here). However, this count can get up (much) higher when used in iterating JSF components (such as <h:dataTable> and <ui:repeat>), or here and there in a boolean expression like the rendered attribute. JSF (specifically, EL) won't cache the evaluated result of the EL expression at all as it may return different values on each call (for example, when it's dependent on the currently iterated datatable row).

Evaluating an EL expression and invoking a getter method is a very cheap operation, so you should generally not worry about this at all. However, the story changes when you're performing expensive DB/business logic in the getter method for some reason. This would be re-executed everytime!

Getter methods in JSF backing beans should be designed that way that they solely return the already-prepared property and nothing more, exactly as per the Javabeans specification. They should not do any expensive DB/business logic at all. For that the bean's (post)constructor, initialization blocks and/or (action)listener methods should be used. They are executed only once at some point of request-based JSF lifecycle and that's exactly what you want.
answered Guru 24.6k points 29 51 75
0 votes
Let's say I specify an outputText component like this:

<h:outputText value="#{ManagedBean.someProperty}"/>

If  I print a log message when the getter for someProperty is called and load the page, it is trivial to notice that the getter is being called more than once per request (twice or three times is what happened in my case):

DEBUG 2014-01-18 02:31:40,104 (ManagedBean.java:13) - Getting some property

If the value of someProperty is expensive to calculate, this can potentially be a problem.

I googled a bit and figured this is a known issue. One workaround was to include a check and see if it had already been calculated:

private String someProperty;

public String getSomeProperty() {

    if (this.someProperty == null) {

        this.someProperty = this.calculatePropertyValue();

    }

    return this.someProperty;

}

The main problem with this is that you get loads of boilerplate code, not to mention private variables that you might not need.
answered Expert 13.2k points 26 40 57

Related questions

0 votes
2 answers 51 views
51 views
asked john Guru 27.1k points 31 47 92
0 votes
2 answers 306 views
306 views
I am working with a rather large app written in JSF 1.2. JSF 1.2 is around 6 years old now. I need to upgrade to JSF 2.0. How painful will this be? I noticed that some attributes in custom tags have been changed etc.
asked john Guru 27.1k points 31 47 92
0 votes
1 answer 56 views
56 views
asked sara Guru 24.6k points 29 51 75
0 votes
1 answer 27 views
27 views
asked smith Geek 15.3k points 14 39 58
0 votes
1 answer 416 views
416 views
Why is it not a good practice to create HttpSessions in JSPs by default?
asked Smita Advisor 7.1k points 10 22 42
...