• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Differents between various techniques to access beans from other beans.

 
massimo tarantelli
Ranch Hand
Posts: 35
Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 17989
47
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
massimo tarantelli
Ranch Hand
Posts: 35
Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks for the answer, anyway i've noticed that the 4) way doesn't work in the constructor...why? thanks
 
Tim Holloway
Saloon Keeper
Pie
Posts: 17989
47
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 35
Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic