9

I often get doubt on these two phases. The following is my understanding:

  1. Apply Request Values

    • In this phase, the submitted values are coming from the request parameter. Then the request values are set into the backing bean ie.setting to components UIInput

  2. Update Model Values

    • In this phase, processed values are transferred from backing bean (UIInput) to managed beans. (It is our custom defined JSF beans).

I am thinking that my understanding is correct. But, reading few articles made me confused. I want to make me more clear on these two phases. Please clarify me.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Krishna
  • 7,154
  • 16
  • 68
  • 80

1 Answers1

19

Apply Request Values

  • In this phase, the submitted values are coming from the request parameter. Then the request values are set into the backing bean ie.setting to components UIInput

That's not entirely correct. The values are not set into backing beans. They are set into components. Basically the following happens for each UIInput component in the component tree:

input.setSubmittedValue(request.getParameter(input.getClientId()));

Here input is UIInput and request is HttpServletRequest.

Update Model Values

  • In this phase, processed values are transferred from backing bean (UIInput) to managed beans. (It is our custom defined JSF beans).

Also not entirely correct. UIInput components are not backing beans. Basically the following happens for each UIInput component in the component tree:

bean.setProperty(input.getValue());

Here, the bean and property is based on the input's valuebinding, e.g. value="#{bean.property}".

All with all, your confusion is clearly in distinguishing between the JSF component tree, the JSF backing beans and the JSF managed beans. The JSF component tree is the one which you've definied in the JSP/Facelets page and as you can obtain by FacesContext#getViewRoot(). The JSF backing beans are Javabean classes whose properties are bound to the component tree using EL such as #{bean.property}. The JSF managed beans are concrete instances of those Javabean classes. They can be request, session or application scoped (and in JSF 2.0 also view scoped). It are the managed beans where the values are actually been set and retrieved.

See also

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • HI BalusC, I agree that I have confused with the backing bean and the managed beans. See my question:http://stackoverflow.com/questions/4713483/difference-between-managed-bean-and-backing-bean. That is answered properly but I have not understood correctly. So, All the backing beans are managed beans aswell. But, not all the managed beans are backing beans. That means, If a managed bean has any of the UIComponent binding property like UIInput in the class, then it is called as backing bean. Am I correct? – Krishna Jan 21 '11 at 01:50
  • Waiting for the answer. If what I said is correct, then I am clear with these two phases. – Krishna Jan 21 '11 at 01:50
  • 1
    No, that's not correct. The property doesn't necessarily need to be an `UIComponent`. Even more, that's not required at all (even the linked *Debug JSF lifecycle* article explains that those `UIComponent` bindings are for pure demonstration purposes only and that in real world you should only use them whenever you want to do more with them than only getting/setting the value). I myself don't agree the answer of Bozho, it is indeed misleading. The difference between a backing bean and a managed bean is IMO best summarized in this single code line: `BackingBean managedBean = new BackingBean();`. – BalusC Jan 21 '11 at 01:59
  • Hi BalusC, Still I am not clearly understand. I have removed accepted mark for his answer:http://stackoverflow.com/questions/4713483/difference-between-managed-bean-and-backing-bean. Can you answer that question with simple example. From your above statement BackingBean managedBean = new BackingBean();: it looks like backing bean and managed bean are same. – Krishna Jan 21 '11 at 02:48
  • @KRishna @BalusC thanks for the discussion. I changed my answer there, but I don't fully agree with @BalusC. The class definition itself is a managed bean as well - otherwise they would've called the annotation @BackingBean. And the backing bean wouldn't be backing anything if you didn't instantiate it via the managed bean facility. In fact, the one-liner above might be what the JSF creators thought, but it is misleading. Spring and CDI for example don't have two terms for bean declarations and bean instances. – Bozho Jan 21 '11 at 07:00
  • 1
    @Krishna: They *look* indeed like the same. The backing bean is the (abstract) **class** definition of a bean which is bound to a JSF view (i.e. backing the view). There is only one of it in the classpath. The managed bean is the concrete **instance** which is been created and put in scope by JSF (i.e. managed by JSF). There can be multiple of them. – BalusC Jan 21 '11 at 11:14
  • @BalusC, Thank you for the reply. In simple terms Backing bean is the bean declaration and Manage bean is the run time bean instance to hold the view values. @Bozho, I too confused with the concepts. Which one is correct?. I would like to have some more discussions on this and come to the conclusion. Is there any official link for the definition? – Krishna Jan 21 '11 at 16:23
  • I have understood from the link http://download.oracle.com/javaee/1.4/tutorial/doc/JSFIntro8.html. Thank you for the answers. – Krishna Jan 21 '11 at 16:39
  • 2
    @Krishna: OK, what makes in your opinion now more sense? @Bozho has by the way somewhere a fair point. Just call them managed beans all the time. It's perfectly valid. – BalusC Jan 21 '11 at 17:02
  • Yes BalusC, I have agreed with your answer. Both the terms are almost the same.Your statement BackingBean managedBean = new BackingBean(); is 200% correct. :) – Krishna Jan 22 '11 at 02:00