I think your explanation was probably clear but my brain is being stupid this morning. I'm going to have to do my usual trick and explain mechanisms in the hope that it illuminates you.
JSF backing beans are POJOs and don't support constructors with parameters in them. Instead, a no-argument constructor is invoked (if present), the managed properties are injected, and - assuming that your platform supports it - the @PostConstruct method (if any) is invoked.
From experience, I can tell you that attempting to do any serious work inside a backing bean constructor is usually painful.
However, bindings are done at View time via the EL interface, and all of the above are in the past by the time that the bindings are attached.
That also applies to a lot of other things besides binding, however, and I have evolved a simple set of strategies that usually suffice.
For a lot of things, I can just do a caching access that checks pre-requisite constructs for NULL and builds them and caches them if they are null. That allows me to do just-in-time resource construction and avoid the overhead of rebuilding things repeatedly. With a side benefit that I can refresh them by just resetting the resource pointer to null. This is a common trick I do for SelectItem lists, among other things.
For some things, such as database record editing, I need a more complex setup. For cases like that, I often inject the bean into a backing bean(s) of predecessor view(s) and have the action methods that lead into the new bean/View invoke methods on the bean. For example: in "bean1", the "edit record action method" may look something like this:
The beginEdit method typically has bean2 fetch the item to be edited from the database and preps it for presentation on the detailEdit view.
Note that this action method will be invoked after the constructor, managed property setters, and postconstruct method but BEFORE any EL expressions are executed, so in the case of bindings, that allows the context for the bound control(s), but doesn't permit manipulation of the controls themselves, since they haven't yet been bound and won't be until the binding methods in bean2 are invoked at EL processing time.