Rule #1 in JSF: Write JSF-specific code only when all else fails. JSF is supposed to be your friend, not your prison.
A lot depends on how this page is going to be accessed.
A common case for me is when I'm about to edit a database record. In that case, I am generally coming from some other JSF page, and the control that sends me to this new page will typically have an action method that invokes a "beginEdit()" method on the new page's backing bean to cause the record to be loaded and the edit bean is initialized. A side benefit of this is that if the load fails, the "from" page can present an error instead of dispatching a bad view.
In JSF2, you can also set up parameterized views if you want. Or use the PrettyFaces add-in. These features allow you to work with "bookmarkable" URLS so that you can jump directly into the target page without coming from another JSF page.
Another option is to use the @PostConstruct annotation to cause logic to be executed after managed properties have been injected. However, this behavior actually is done when the Model is created, not the View (page), so the ability to literally act on "page load" is dependent on scope and usage.
Likewise the method you indicated of attaching code to an outputText element. I frequently use a variant of this to initialize selection lists. The main problem here is that you have the same caveats as on @PostConstruct, plus ideally you should include mechanisms to avoid performance and/or side effects that can come when a single view request accesses the property more than once (a frequent occurrence in JSF). A variation of this technique I use in conjunction with things like "beginEdit()" above invalidates any previously-cached information so that a new page load would then update the data.
There are other techniques as well, but most of what I do manages with just a few of the above techniques. And, if you look at them in detail, pretty much none of them require any javax.faces class methods, hooks into the JSF framework or the FacesContext - they're POJO code. Hence Rule #1.
One thing that does require special attention in JSF is the postback mechanism. There are 3 kinds of page loads to keep in mind:
1. Page load due to initial request for page.
2. Page load in response to postback
3. Return to a page previously used (possibly with different data).
Blitzlügen - Lies or information broadcast, but when called out the broadcaster does little or nothing is done to correct them, thus allowing those who wish to believe to accept them as truth.
Lügensturm - A barrage of Blitzlügen fired in such quick succession that it is essentially impossible to correct them all.
Could you hold this kitten for a sec? I need to adjust this tiny ad: