Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

First Load of a Page and Input pre-selection  RSS feed

 
Carlos Conti
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I have the following dilema, the solution for which, will clarify me some basic concepts about the JSF lifecycle .

when I first load a page, the JSF lifecycle renders the controls for that page for the first time during the renderresponse phase. I have a PhaseListener which depending on the upcoming managedbean executes a method of that managedbean, in which I set some predefined values on input controls (without 'value' attribute->input controls not bound to the datamodel). This method is executed right before the renderresponse phase. This means that when loading the page for the first time I am not able to preset input values (through 'bindings') because they are null instances, by the time I try to set them. Of course once the page is loaded, this first run of the renderresponse phase for the page is already done, and if I refresh the page, everything solves, then now the input bindings are not null and values can be preset.

A solution I have figured out is to create artifitial managedbean fields which can be used as the backing fields for those input 'value' attributes, which allows me to get rid of the bindings aswell. However I find the bindings are more elegant. But even trying to set the values after the renderresponse doesn't update them, 'cause the response has been already sent.

Can I do something to keep using bindings? Of artifitial members are a well accepted solution?

Regards,
Carlos.
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure, but it sounds like you're attempting to solve a common problem, although by a somewhat more complex mechanism that most such attempts really require.

Consider this classic example. Say you have a popup menu that contains items from a database. That menu has to be initialized before use - meaning that the database has to be queried and a SelectItem list needs to be constructed. Many people have learned to their sorrow that this is NOT something that the "get" method for the selectlist should be doing. I had to bail out some poor soul just the other day because of side-effects in a "get" method, in fact.

On the other hand, you can't do this in a constructor if the context for setting up the list is injected from faces-config, since the injections happen after the constructor exits.

There's basically 2 solutions to this problem, assuming you don't want to construct elaborate JSF-specific mechanisms. The old-fashioned way would be to partially break the "no side effects in constructor" rule like so:


The second approach involves using the @PostConstruct annotation to define a method that's invoked after construction and injection, but before the bean is used for application purposes. PostConstruct is a little "iffy" at the moment, since you have to have a certain minimum level of support in your framework, but it's overall a lot cleaner if you can use it.
 
Carlos Conti
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Tim for your answer. Well I have built a simple JSFmechanism as you say which consists an initialization and disposal methods which are called from the phaselistener when the main ManagedBean (in charge of handling the current page) changes.

In those methods is where I build and pre-set values for input controls. For the time being I am moving forward whith those artificial fields, and works fine, but at the same time I find strange that pre-setting values in the first load of the page (and I really mean ONLY the first load-> JSF must hold appart session beans in charge of the page rendering) is not possible, unless you can create the binding before the first execution of the renderresponse phase for the page, which sounds (I must admit) like non-sense (hahaha)... but well that is the weakness of the mechanism I have designed.

Regards and thanks again for your answer.
Carlos.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!