aspose file tools*
The moose likes JSF and the fly likes Differents between various techniques to access beans from other beans. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Differents between various techniques to access beans from other beans." Watch "Differents between various techniques to access beans from other beans." New topic
Author

Differents between various techniques to access beans from other beans.

massimo tarantelli
Ranch Hand

Joined: Jun 19, 2012
Posts: 35

Hello to everybody,
to acces a Beans from an other one I know these ways:
1)


2)


3)


4)


which are the differences, and when one is better from an other?
thanks

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16137
    
  21

Whenever possible, use case 4 - POJO injection. If you'll notice, it doesn't require any specialized JSF code (annotations don't count - you can do the same thing via faces-config.xml).

By sticking to Inversion of Control POJO principles and not using framework-specific constructs, you insulate yourself from changes in the framework (The EL interface changed markedly between JSF1 and JSF2), you make it more likely that you can reuse the component in non-JSF projects, and you make it easier to test stand-alone where neither JSF nor a webapp container are running.

Note, however, that in order for this to work, you must also include a "set" method for the property which you wish to set. Otherwise the JSF framework cannot initialize the managed property, since it doesn't have any magical powers that allow bypassing normal protections for private members.

I could give an entirely separate lecture on the perils of user-defined logins, but that wasn't the question here.


Customer surveys are for companies who didn't pay proper attention to begin with.
massimo tarantelli
Ranch Hand

Joined: Jun 19, 2012
Posts: 35

thanks for the answer, anyway i've noticed that the 4) way doesn't work in the constructor...why? thanks
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16137
    
  21

massimo tarantelli wrote:thanks for the answer, anyway i've noticed that the 4) way doesn't work in the constructor...why? thanks


I didn't understand that. If you mean that managed property values are not available when the constructor executes, that's true. That's because the constructor is the very first thing that executes when you create a bean - you cannot apply the setUserLogin() method to an object that doesn't exist yet.

First the constructor is invoked. In JSF, this will always be a no-argument constructor as there is no provision in JSF to pass parameters to a managed bean constructor (and in any event, good JavaBean practice recommends always providing a no-args constructor).

Then the Managed Properties are set to inject values into the newly-constructed bean. It is good practice not to assume that these setter methods will be called in any particular order.

Finally, if the system supports it, the @PostConstruct method will be called, if one is defined. At @PostConstruct time, the bean has been fully constructed and all managed properties have been set.

After PostConstruct time, the bean can be used generally with confidence that it is properly initialized. Views can set/get properties, action methods can be invoked, and so forth.
massimo tarantelli
Ranch Hand

Joined: Jun 19, 2012
Posts: 35

If you mean that managed property values are not available when the constructor executes, that's true.

It was what I meant.
thanks for the complete explanation.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Differents between various techniques to access beans from other beans.