• 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

¿How to manage a bean in jsf 1.2 and seam framework 2.0.2?

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi im totally new to this tecnology and im facing the chalenge to do some maintenance to an app, so here is my problem im trying to add a new value to a related entity of a model





My problem is that i dont know when or how a bean is managed, and i need to manage the bean so i can pass the new value moneda to the facturaHome.itemFacturasTemp
 
Saloon Keeper
Posts: 27752
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
¡Welcome to the JavaRanch, Sr. Perez!

JSF has a special bean management subsystem whose sole function is to instantiate JSF backing beans and inject Managed Properties into them. Once that has been done, the managed beans look just like any other J2EE application, session or request-scope objects. Instantiation is done on-demand. That is, if a View is requested and there's an EL expression on the View Template (.xhtml) that references a bean such as facturaHome, the EL processor attempts to find a J2EE object of that name and use it. If one cannot be found, then the JSF bean manager takes over, instantiating a bean and returning it for processing.

Managed Beans are all POJOs. This means that you must have either a no-argument constructor for it or at least not have any explicit constructors that require arguments and thus obstruct the ability of the bean manager to instantiate a copy of the managed bean without constructor arguments. Managed Properties are simply EL expressions that return a value that can be injected into the managed bean via its public "set" methods. So first the bean is instantiated, then the Managed Properties are injected, then the bean is presented for use.

Defining a managed bean in JSF1 was done via XML ManagedBean elements in the faces-config.xml. In JSF2, it was also possible to define managed beans and their managed properties via annotations on the bean's Java source.

CDI is an attempt to consolidate a number of different bean management functions under a common annotation set, and it looks like that's what you're using. I haven't been using CDI because it's not compatible with my legacy code, thus I'm not an expert on it. However the important things to do whether you use JSF annotations or CDI annotations is to mark the bean as managed and to define the JSF scope of the bean - application, session, view or request-scoped.

Incidentally request scope is almost 100% useless in JSF and doubly so when using JSF model façade objects - meaning selectOneMenu or dataTable elements. Use ViewScoped if your bean is only required for processing that particular page, and SessionScoped if more than one page needs its contents/capabilities.

That's how beans come into the world in JSF. What I think you REALLY wanted to know, however, is how data gets in and out of Managed Beans. Initially, as I said, ManagedProperties can inject values into a ManagedBean. But once the bean has been rendered up as a web page, what then?

Well, JSF is a Model/View/Controller architecture. The xhtml View Templates define Views, the backing beans are Models (and action processors, which are something outside of MVC). And the Controllers are all pre-supplied for you. You don't write Controller logic for JSF. You don't have to.

Once a bean's property is bound to a control in a View via an EL expression referencing it, JSF's lifecycle processing will automatically ensure that changes to the View such as selection made on the "activa" control are copied to the Model (item.moneda). Since "item" is a row cursor for the dataTable, that means that the corresponding facturaHome.itemFacturasTemp row's "moneda" property is automatically set by JSF. Conversely, when the View is rendered, whatever value was in that property will be reflected in the rendered web page.

It is important to be aware, however, that JSF is built on HTML/HTTP. That means that nothing will work right unless the control is in a from (JSF h:form) and that simply changing the control won't update the backing bean. The form has to be submitted, either via a submit control (h:commandButton or h:commandLink) or via AJAX. Once the form has been submitted, the JSF lifecycle takes over - inputs are validated, and - if valid - listeners are invoked, the bean's properties are updated and the submit action method and/or listener method(s) are fired.

 
reply
    Bookmark Topic Watch Topic
  • New Topic