Unexpected Visualforce Order of Execution with component attributes on Get Request

Question

I've hacked this small example of the unexpected order based on Order of Execution for Visualforce Page Get Requests. From the linked docs (my empahsis):

1. The constructor methods on the associated custom controller or controller extension classes are called, instantiating the controller objects.
2. If the page contains any custom components, they are created and the constructor methods on any associated custom controllers or controller extensions are executed. If attributes are set on the custom component using expressions, the expressions are evaluated after the constructors are evaluated.
3. The page then executes any assignTo attributes on any custom components on the page. After the assignTo methods are executed, expressions are evaluated, the action attribute on the component is evaluated, and all other method calls, such as getting or setting a property value, are made.
4. ...

This isn't lining up with what I'm seeing in the debug logs.

6   USER_DEBUG  [4]     DEBUG   myController constructor called. Visualforce page controller
9   USER_DEBUG  [8]     DEBUG   myController actionMethod Visualforce page action method called
15  USER_DEBUG  [11]    DEBUG   componentController constructor called.
19  USER_DEBUG  [5]     DEBUG   selectedValue set in componentController
24  USER_DEBUG  [5]     DEBUG   selectedValue set in componentController

Note how the actionMethod on the parent Visualforce page is called before the component constructor and any of the custom component assignTo properties are set.

Basically, why is the page controllers action method being called immediately after the constructor and before the components are ready?

I've got components where I want to call methods on them from the controllers action method. This, of course, requires them to have been constructed first.

---

These are all using v36.0 from Spring '16.

Component Controller:

public class componentController {
    public String selectedValue {
        get;
        set {
            System.debug(LoggingLevel.Debug, 'selectedValue set in componentController');
            selectedValue = value;
        }
    }

    public componentController() {
        System.debug(LoggingLevel.Debug, 'componentController constructor called.');
    }
}

Component:

<apex:component controller="componentController">
    <apex:attribute name="value" type="String" description="Sample component." assignTo="{!selectedValue}"/>
    <p>
    Value = {!value}<br/>
    selectedValue = {!selectedValue}<br/>
    </p>
</apex:component>

Controller:

public with sharing class myController {

    public myController() {
        System.debug(LoggingLevel.Debug, 'myController constructor called. Visualforce page controller');
    }

    public void actionMethod() {
        System.debug(LoggingLevel.Debug, 'myController actionMethod Visualforce page action method called');
    }

}

Visualforce page:

<apex:page controller="myController" action="{!actionMethod}">
    <apex:messages />
    <apex:pageBlock title="Component page block">
        <c:editMode value="{!$CurrentPage.parameters.key}"/>
    </apex:pageBlock>
</apex:page>

Answer 1

Relaying a response from Michael Alderete - Technical writer for the Salesforce docs team. Slightly modified for context.

---

While I believe all of the behavior you’ve described [...] is expected, I don’t think you’re misinterpreting the docs. You’ve found an area that could be documented a little more clearly.

1. This is expected behavior. The page-level action method is called early, as a consequence of accessing the page. This is so that the page can redirect if that's desired.

The description for this attribute explains this (or, rather, tries to):

"The action method invoked when this page is requested by the server. Use expression language to reference an action method. For example, action="{!doAction}" references the doAction() method in the controller. If an action is not specified, the page loads as usual. If the action method returns null, the page simply refreshes. This method will be called before the page is rendered and allows you to optionally redirect the user to another page. This action should not be used for initialization." - Source

However, you're correct that it's not in the diagram and doc you've pointed to in your tweet. I'll create a doc bug to update it.

2. Regarding "the double property calls (another oddity)", this is also expected. Getters and setters may be called more than once per page request. This is why we document that they should be idempotent, that is, not have side effects.

3. Regarding timing of the doc updates, it's actually updated every week. Doc is on the same weekly patch release schedule as the app itself. It's just that there's a lot of things to work on, so there aren't changes to the Visualforce docs every week.