• 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

Correct way to assign a value to a managed bean from a class?

 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

Currently I'm using the following code in one of my classes:



But the type ValueBinding is deprecated.

What is the currently accepted method to do this?

Thanks.
 
Amy N. Snow
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think I found out the current way to do it:

 
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
Any time you import a javax.faces class to do work for you, there's a possibility that you're doing it "wrong". The exception to the rule are the datamodel classes, which simply can't be helped.

A better way to access managed beans is by using simple injection under the Inversion of Control (IoC) model. In the case of Managed Beans being the recipients of other classes, use the managed-property feature of the faces-config.xml file. That's how I inject the business and persistence beans into my managed beans, and it requires no JSF or EL code at all, just a simple setter for the property in question. Basic JavaBeans. Also very portable. You don't need all that infrastructure to use or to test the managed bean.

Usually I can do what I want that way. but in a few cases I need to "pull" a request or session object instead of having it pushed (injected). For that I keep a separate JSFUtils class that does things like look up session beans. By doing that, I keep the javax.faces code out of my managed beans, simplify my logic (JSFUtils.getSessionAttribute("x")) is a lot tidier than chasing down the path of a FacesContext), and make it easier to test my beans outside of a webserver environment.
 
Amy N. Snow
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tim:

I want to pass a value from the Form bean, that is session scoped, to the Message bean that I have already in the faces-config.xml (and I want the message to be request scoped), but I don't understand how can I setup a managed-property to do this.

I have this managed bean:



If I set the other managed bean like this:



When the session is terminated the orderMsg bean will be empy because the form bean was destroyed, right?


Can you give me an example of how could I do this with managed properties?

Thanks.
 
Tim Holloway
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
Somebody's been working with Struts, I think.

A session-scope object has a fairly long lifetime. Unlike request-scope objects, which are created and destroyed every time you submit a request, session objects, once created, live until the session itself is destroyed, either explicitly or because the session timed out due to inactivity. So no, you won't lose your "form bean" (or more accurately speaking, your Managed Bean named "form"). Therefore you can safely inject it into any bean of equal or shorter lifespan - meaning that session beans can be injected into other session beans and/or request beans, but request beans cannot be injected into session beans (JSF will throw an error, if you try).

Occasionally this restriction requires a little creativity. For example, you might need to inject in the other direction in order to satisfy these restrictions. That is, if you a have a request-scope object that needs to be processed by a session-scope object, you'd have to inject the session-scope object into the request-scope object, then have the request-scope object perform a callback on the injected object. That's not as awkward or unnatural as it may sound, just takes getting used to the Inversion of Control way of doing things. IoC isn't unique to JSF - the Spring Framework, for example is all about IoC.

Occasionally JSF scoping and postback requirements - mostly postback requirements - will cause you to have to put things in session scope that you'd rather keep in request scope. I've never been very happy with this, but if it's a real problem, there are workarounds. Just not automatic, or intuitive ones. People are working on this, though.
 
Amy N. Snow
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks again Tim. Let me see if I understood correctly.

Tim Holloway wrote:Somebody's been working with Struts, I think.



Not Struts, I'm using MyFaces Trinidad components (Ajax enabled JSF components)

A session-scope object has a fairly long lifetime. Unlike request-scope objects, which are created and destroyed every time you submit a request, session objects, once created, live until the session itself is destroyed, either explicitly or because the session timed out due to inactivity. So no, you won't lose your "form bean" (or more accurately speaking, your Managed Bean named "form"). Therefore you can safely inject it into any bean of equal or shorter lifespan - meaning that session beans can be injected into other session beans and/or request beans, but request beans cannot be injected into session beans (JSF will throw an error, if you try).



I'm explicitly invalidating the session in my example, but I see I was doing it the other way around in the example of my previous post.
Although, if I inject the orderMsg property (a property in my Form class) on the form Managed Bean into the orderMessage Managed Bean message Managed Property and I invalidate the session when I'll try to retrieve the #{orderMessage.message} property it will be empty.

Occasionally this restriction requires a little creativity. For example, you might need to inject in the other direction in order to satisfy these restrictions. That is, if you a have a request-scope object that needs to be processed by a session-scope object, you'd have to inject the session-scope object into the request-scope object, then have the request-scope object perform a callback on the injected object. That's not as awkward or unnatural as it may sound, just takes getting used to the Inversion of Control way of doing things. IoC isn't unique to JSF - the Spring Framework, for example is all about IoC.



Based on what you just mentioned above I understand that I would have to have a request-scoped Managed Bean that holds the "message" and somehow set the value of orderMsg in the form Managed Bean ("perform a callback") but I don't see a way to perform this callback using the Managed Beans facility.

Can you guide me?


Thank you.
 
Tim Holloway
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
Callbacks aren't part of JSF. Like JavaBeans, they're general-purpose constructs.

So if I have a bean containing data that came from a JSF View (form) that's in Request scope, injected a helper object that's in Session scope, and that helper object had some sort of method named something like "storeMessage" that could take data from the request object and pass it to the helper object, which would then do whatever it wanted to. For example, take the captured form data and persist it out to a database - possibly using a persistence-layer object (injected into the helper object) to do the actual database work.

Although I said that the callback you create could take individual items, it's also valid to just pass the entire bean named "form" that way as well. Which effectively does what your original example did but without having explicitly to rely on javax.faces classes and methods. The difference is more portability, more readability, more flexibility, and more immunity to changes in the JSF API, since nothing is required but straight (non-J2EE) method calls. All JSF does is ensure that the beans are built when needed and that they are wired together properly, and that's all done in faces-config, not in explicit program logic.
 
Clowns were never meant to be THAT big! We must destroy it with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic