Well, if you mean do the properties get accessed via the "get" methods, I believe that they don't.
On the other hand, "get" methods should not have side-effects, so whether or not they were invoked should not be a major issue.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Apr 21, 2010
thanks for your answer. I omitted one small but important detail... it is not the 'get' expressions for input control values which make the code fail, but the component bindings. The situation is that I have file which is under a certain condition included in my main template (almost 100% of my views are based on that template), but the point is that the file contains a component which is an extension of the ice:selectInputText component, and need to 'bind' it to an instance in the backing bean, but that instance is sometimes null, because the context hasn't supplied a critical value to call its constructor. That's why I expected to avoid the problem by means of setting at an upper level in the view tree, a rendered attribute which would prevent the component from rendering when that value was not supplied, and this way bypassing the NullPointerException.
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.
subject: rendered attribute and backing bean calls