• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

rendered attribute and backing bean calls

 
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Carlos Conti
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic