• Post Reply Bookmark Topic Watch Topic
  • New Topic

how to use ui:param in facelets  RSS feed

 
Piter Smith
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How are methods invoked on the `bird` parameter?


next.xhtml:



MyQueueBean:



`MyQueueBean` is intended to give out a bird once only, to exactly one end-user. Because it's application scoped, and not session scoped, getting attributes directly from the bean would give inconsistent results.


The birds application is from Facelets Essentials Guide to JavaServer Faces View Definition Framework:

http://www.apress.com/9781430210498




how is the variable passed to the file? Once it's passed, how is it referenced?

 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Annotating an application-scope bean as Singleton is redundant. By definition, there's only one instance of it per application.

The problem here is that although your property is only coded once and for a single user, its get method has side-effects.

JavaBeans in general and specifically JSF backing beans should not have side-effects in their get/set methods. A get method for a property might be invoked 5 or 6 times in the course of a single request/response cycle.

The way around this is to back up the get/set methods by an actual instance variable (property item) and have the get/set methods set or retrieve that variable's value.

For a read-only property such as this one, the backing property variable can be initialized either in a @Postconstruct method or by coding the "get" method to employ the variable as a cached item. That is, on the first call, retrieve the value from the database and set the variable, on subsequent calls just return the variable.
 
Piter Smith
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:Annotating an application-scope bean as Singleton is redundant. By definition, there's only one instance of it per application.

The problem here is that although your property is only coded once and for a single user, its get method has side-effects.

JavaBeans in general and specifically JSF backing beans should not have side-effects in their get/set methods. A get method for a property might be invoked 5 or 6 times in the course of a single request/response cycle.

The way around this is to back up the get/set methods by an actual instance variable (property item) and have the get/set methods set or retrieve that variable's value.

For a read-only property such as this one, the backing property variable can be initialized either in a @Postconstruct method or by coding the "get" method to employ the variable as a cached item. That is, on the first call, retrieve the value from the database and set the variable, on subsequent calls just return the variable.


by side effect, you mean mutate fields?
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A side-effect is the opposite of idempotent. An idempotent method returns the exact same value every time you invoke it. A method with side-effects might not.

By "every time", I mean in the absence of interim processes external to that method changing its backing value. Most notably the corresponding "put" method, but also things like action processors. The point is that other code might change the value, but the "get" code - and any code that the "get" code invokes - must not.

JavaBean and JSF "get" methods should not have side-effects, and for best performance, they should not indulge in resource-intensive operations. Since, as I said earlier, you don't know how many times a "get" method is going to be invoked on a given JSF request/response.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!