Page Initialization

Every web page comes with a set of corresponding @ViewScoped managed beans. The initialization process of these beans has three steps, that are executed one after the other, in different JSF lifecycle phases, in the following order (top to bottom).

Step	Time of execution
No-args constructor	called when an EL expression needs to reference the managed bean for the first time
init() method with @PostConstruct	This normally happens in the “Update model values” phase.
initApplication() method	This happens in the “Invoke application” phase. The method is indirectly called with the help of a generated <f:viewAction> tag in a page’s main XHTML page.

The following table shows how the different beans are being initialized.

Managed Bean	Initialization
[Name]Bean.java	first init() and then, later initApplication()
[Name]BeanCustomization.java	init() only
[Name]BeanDevTooltip.java	init() only
[Name]BeanExtendedCustomization.java	init() only
[Name]BeanNavigationCustomization.java	init() only

The initApplication() in [Name]Bean.java is the only place where you should read data that you need to initialize the web page, e.g. from a database or a webservice. Also, this bean has all the event handlers for the corresponding page. So from here writing to databases, calling webservices and navigating to other pages is being done. Additional constructors with parameters will never be called by a JSF framework. Note that the initApplication() will only be called for an HTTP GET request. This means that in case of AJAX calls with navigation included, you should prefer the POST/REDIRECT/GET PATTERN. You do this by appending ?faces-redirect=true to a navigation case, e.g. like this:

puublic String actionFoo() {
    ...
    return "/abc/xyz.xhtml?faces-redirect=true";
}

Limitations of faces-redirect

The query parameter faces-redirect doesn’t have any effect when you append it to a redirect call with externalContext.redirect(...). The parameter also doesn’t have any effect when it is part of an icoming HTTP request, sent by an HTTP client. The String-typed return value of an action...() method is processed by a JSF framework, though. And therein is the logic of turning a PAGE FORWARD into a REDIRECT/GET.

Working with Query Parameters

There is generation support for query parameters. You can model the query parameters that a page “understands”. In the model they are called “InitParameters” since this is a more common way of naming this. And the model shall remain as technology-independent as possible.

type InitParams {
    field callOption : sint32 {
        set Java-UsePrimitiveWrapper = true;
    }
}

layout PurchaseAssistant {
    set Type = Wizard;

    link InitParameters = InitParams;
    ...
}

As a result there is code generated that lets you easily use a query parameter named ‘callOption’ in your managed bean [Name]Bean.java. An inner class InitializationParameters is getting generated. That class has a field private Integer callOption; and your managed bean has a field private InitializationParameters initParameters. The value is set when a user navigates to the ‘PurchaseAssistant’ page and uses the query parameter like this: .../purchaseassistant.xhtml?callOption=5. Finally, you can use the query parameter in your bean code like this. You don’t have to do anything else to make the value available.

...
Integer callOption = 0;
if (getInitParameters().getCallOption() != null) {
    callOption = getInitParameters().getCallOption();
}
this.webservice.foo(callOption);
...

Note

There is a plus to the code that is automatically generated: The “interface” of a web page is now documented in a standardized way.