1

I have a basic question. I have a big VF page with many sections which render/hide based on some flags. The flags are set in constructor of controller extension and are mostly depend on the logged-in user profile, role etc. (i.e. they do not change value). Now I am trying to make my constructor thin and move these flags outside it in getter/setter methods. However, I want to know if these getters will always be called when they are referenced in 'rendered' on multiple sections etc. (i.e. the flags are referred in VF page multiple times). When I did some testing, it looks like they are called only first time but want to confirm my understanding. With the flags being set in constructor, I am assured that they will run only once when the page loads. But I want to reduce the code in constructor.

4

I have observed Apex properties - a convenient way to implement getters and setters - only being referenced once even though the Visualforce includes multiple references. It seems like there is some caching of values being done but I don't remember seeing any documentation that guarantees that behaviour. So I write controllers assuming that the properties can be referenced multiple times; certainly when referenced in Apex tests they can be. For efficiency and to stay within governor limits, that means often calculating the value once and then holding on to the result and returning just the result in any further references.

Two strategies to accomplish this are:

  1. As you have done, set the properties in the constructor; you can break out the work into multiple methods that you call from the constructor if the amount of code is large.
  2. Use lazy initialisation for the properties as described below.

Here is an example of lazy intialization:

public Integer total {
    get {
        if (total == null) {
            total = [select count() from Contact where ...];
        }
        return total;
    }
    private set;
}

The first time total is referenced the query (or other expensive logic) is done and the value assigned to the field. On subsequent references the field value is returned without the query being done. An advantage of this pattern over setting the properties in the constructor is that if the set of properties referenced varies depending on conditional page logic then only the initialization for the properties that are actually referenced is done so avoiding the waste of calculating the unreferenced properties. The approach works equally well for static fields.

  • Thanks @Keith C. I agree that getters are easy to implement. When I debugged, it looks like they run only first time. But did not see this written anywhere in the documentation. Your answer helps! – TJD Oct 24 '15 at 22:15
  • I liked the lazy initialize technique you described. However I want to know how I can leverage it for Boolean property. I have to return Boolean based on some conditions which I will perform inside get. How should I write that null condition then. Boolean by default is false I believe. – TJD Oct 25 '15 at 18:34
  • @TJD The same pattern works for Boolean because in Apex a Boolean is also an object so the object reference can be null. (Java, by comparison, has both a boolean primitive and a Boolean object.) – Keith C Oct 25 '15 at 18:46
  • I found one interesting thing on boolean behaviour. Uninitialized boolean if accessed in controller will return null. However, the same if accessed in VF page return 'false'. public boolean flag{ get{ System.debug('flag::'+flag); return flag; } } Above System.debug returns null. But same property if accessed in VF return false. – TJD Oct 25 '15 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.