Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes JSF and the fly likes rendered attribute and backing bean calls Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "rendered attribute and backing bean calls" Watch "rendered attribute and backing bean calls" New topic
Author

rendered attribute and backing bean calls

Carlos Conti
Ranch Hand

Joined: Apr 21, 2010
Posts: 113
Hi all,

I know this is a very basic question, but there's still something I still don't exactly know...

If a component has it's rendered value set to false, do the inner EL backingbean calls get called anyway?

Is there something to avoid that and expect that the inner component expressions are not called?

That would ease quite a lot one piece of my project.

Thanks in advance,

Carlos.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15958
    
  19

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.
Carlos Conti
Ranch Hand

Joined: Apr 21, 2010
Posts: 113
Hi Tim,

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.

Hope the explanation was clear.

Regards,

Carlos.

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15958
    
  19

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: rendered attribute and backing bean calls
 
Similar Threads
How to get to the custom tags on a page from a scriptlet?
Question on rendering
Bean request Scope won't Call method
Setting "rendered" attribute via javascript?
Javascript nested function