Order of execution of controller method calls during rerender

Question

Let's say we have an apex:commandButton, with immediate="false", and no apex:actionSupport. It's just a standard apex:commandButton inside an apex:form.

Additionally, suppose it has a reRender attribute which rerenders some form elements.

This page leaves out an important detail:

Order of Execution for Visualforce Page Postback Requests

Namely, when the various form elements are rerendered, you may imagine that some of them will call methods on the controller. For example, there may be some methods called to retrieve Boolean values to control the "rendered" attribute of certain elements. Additionally, elements such as apex:selectOptions may call methods on the controller to retrieve List<T> for their "value" attribute.

Is there any defined order for these method calls, or is it non-deterministic?

Here is one of my use cases where this is important. I have an apex:selectOptions which calls a controller action in its "value" attribute. Let's call this action "getOptions()". This must be run at postback time, as its contents are sensitive to certain controller member variables that are assigned by input elements during the postback. Also, I have some sections on the page that either render, or do not, depending upon whether "getOptions()" contains any data.

It would be ideal not to have to make 2 SOQL queries, one for the List and the other to retrieve a COUNT() aggregate, using the same predicate, but I can't see another option, since getOptions() may not have been called by the time the other element needs to know how many options were returned. It seems I need another method, getOptionCount() in order to be guaranteed to get the count.

Answer 1

You can't depend on the order of setters or getters. You should avoid doing this at all cost. In fact, you can't even guarantee that your setters or getters will be called only once per transaction, so your "two queries" might very well become four or six (or more!), depending on page structure.

If you must use this design, then opt for "lazy initialization", like so:

transient SObject[] records { get; set; }

void loadRecords() {
    if(records == null) {
        records = [select ... from ... where ...];
    }
}
public SObject[] getOptions() {
    loadRecords();
    // Do something with records
    return someArray;
}
public Integer getOptionsCount() {
    loadRecords();
    return records.size();
}

This makes sure your query is ran only once per transaction without regards to how many times your getters might be called. If view state size unimportant, you can simply assign the value during your action methods whenever they need to be updated. The bulk of any rendering you do should be within constructors or action methods, not getters or setters.